BDD和TDD之间的关系

BDD和TDD是什么关系？

据我了解，BDD在TDD之上增加了两个主要内容：测试命名（确保/应该）和验收测试。在BDD开发期间，我应该遵循TDD吗？如果是，我的TDD单元测试是否应使用相同的sure / should样式命名？

BDD在TDD周期周围增加了一个周期。

因此，您从一个行为开始，让其驱动测试，然后让测试驱动开发。理想情况下，BDD由某种验收测试驱动，但这不是100％必要的。只要定义了预期的行为，就可以了。

因此，假设您正在编写一个登录页面。

从幸福的道路开始：

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

在行为驱动的开发中，这种“先有后有”的语法很常见。它的优点之一是可以由非开发人员阅读（并通过培训，以书面形式），也就是说，您的利益相关者可以查看为成功完成任务而定义的行为列表，并查看它是否在您发布不完整的产品之前很久就达到了他们的期望。

有一种称为Gherkin的脚本语言，与上面的代码看起来很像，并且允许您在这些行为的子句后面编写测试代码。您应该为通常的开发框架寻找基于Gherkin的翻译器。那超出了这个答案的范围。

无论如何，回到行为。您当前的应用程序还没有执行此操作（如果执行了，那么为什么有人要更改？），因此，无论您是使用测试运行程序还是只是手动进行测试，您都无法通过该测试。

因此，现在该切换到TDD周期以提供该功能了。

不管您是否编写BDD，都应使用通用语法来命名测试。最常见的一种是您描述的“应该”语法。

编写测试：ShouldAcceptValidDetails。经历“红绿色重构”循环，直到对此感到满意为止。我们现在通过行为测试了吗？如果不是，则编写另一个测试：ShouldRedirectToUserDefaultPage。红绿重构，直到您满意为止。洗涤，漂洗，重复直到达到行为中规定的标准。

然后我们继续下一个行为。

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

现在，您不应该抢先通过此操作来传递您以前的行为。此时您应该通过此测试。因此，请回到您的TDD周期。

依此类推，直到您拥有自己的页面为止。

强烈推荐Rspec书，以了解有关BDD和TDD的更多信息，即使您不是Ruby开发人员也是如此。

我对此的理解：

• BDD最初是TDD的品牌重塑，目的是使行为更加清晰。
• 它为行为和可执行规范提供了更多的正式支持（DSL和工具）。
• 现在可以将BDD视为TDD的超集。它已经随着时间的推移而增长，以涵盖事物的更多需求引发方面，但是开发过程仍然是其中的核心部分。

因此，要解决TDD中BDD正确的部分。BDD最初是为了改变TDD的语言而提出的，目的是使流程的意图更加清晰。 Dan North在BDD上的介绍性文章解释了为什么只关注单词行为而不是测试是有用的-它有助于确认您不仅在构建正确的软件，而且还在构建正确的软件。这始终是良好的TDD方法的一部分，但Dan稍微将其编入BDD。

我认为BDD比TDD更为明确，或者至少是形式化并提供工具支持，是这种两周期/双循环/放大/缩小/由外而内的方法。首先描述功能的预期行为（外部循环），然后放大到内部循环以处理底层规范。

从http://www.metesreau.com/ncraft-workshop/

Gherkin与诸如Cucumber和SpecFlow之类的工具一起提供了一种编写这些高级功能规范，然后将它们链接到执行应用程序代码的代码的方法。我认为这是BDD与TDD可能“有所不同”的地方，但实际上它仍在做同样的事情，只是增加了一些工具支持和DSL。更接近“传统” TDD的是使用诸如rspec，nspec，spock之类的工具。这些感觉有点像您在“传统” TDD中所做的相同过程，但是具有更多以行为为中心的语言。

在John Ferguson Smart的《 BDD in Action》（强烈推荐）中，他主张采用双循环方法，首先从外部可执行规范的jBehave之类的东西入手，然后再从Spock等低级规范的工具入手。

BDD使测试驱动的概念更接近业务利益相关者。Gherkin的设计具有商业可读性，“活动文档”的思想（即，根据您的可执行规范自动生成的进度报告）旨在向利益相关者提供反馈。

现在，BDD的另一部分是需求启发，而BDD真正地变成了将TDD纳入更大流程的一部分。功能注入，影响映射和实物选项等想法是这一方面的一部分。

对于这个问题的典型答案，最好再去丹·诺斯。如果您的团队是所有开发人员，则BDD = TDD。如果您的团队涉及所有利益相关者，那么BDD更接近XP，而TDD就是其中的一部分。

BDD和TDD是什么关系？

他们是一样的东西。

据我了解，BDD在TDD上增加了两件事：测试命名（确保/应该）

这并不是BDD真正添加的东西。这只是一个不同的约定，旨在使教学和理解TDD更容易。

创建BDD的人都在教TDD，他们注意到最难理解的是TDD与测试完全无关。一旦学生克服了这一障碍，对他们来说就容易多了。但是，当“测试”一词（或诸如“断言”之类的相关术语）几乎随处可见时，很难摆脱对测试的思考。因此，他们转了一些字。

但这只是话！有没有 TDD和BDD之间的实际差异。

和验收测试。

验收测试与BDD一样，在TDD中同样重要。同样：TDD和BDD之间没有区别：正确的TDD 是 BDD，正确的BDD 是 TDD。