TDD和BDD之间的主要区别是什么？
What are the primary differences between TDD and BDD?

我理解BDD更多是关于规范而不是测试 。 它与域驱动设计相关联（你不喜欢这些* DD缩略词吗？）。

它与编写用户故事的某种方式相关联，包括高级测试。 Tom ten Thij的一个例子：

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

（在他的文章中，Tom继续在Ruby中直接执行此测试规范。）

BDD的教皇是Dan North 。 您将在他的BDD简介文章中找到一个很好的介绍。

您将在此视频中找到BDD和TDD的比较。 还有一个关于BDD的观点是Jeremy D. Miller所说的“TDD做得对”

2013年3月25日更新

上面的视频已经缺失了一段时间。 这是Llewellyn Falco最近的一篇， BDD与TDD（解释） 。 我发现他的解释清楚而且非常重要。

对我来说，BDD和TDD之间的主要区别在于焦点和措辞。 而言语对于传达你的意图很重要。

TDD将重点放在测试上。 而且，由于“旧瀑布世界”测试在实施后出现，因此这种心态会导致错误的理解和行为。

BDD将注意力集中在行为和规范上，因此瀑布思维分散注意力。 因此，BDD更容易被理解为设计实践，而不是测试实践。

似乎有两种类型的BDD。

第一个是Dan North讨论的原始风格，它引发了xBehave风格框架的创建。 对我来说，这种风格主要适用于验收测试或针对域对象的规范。

第二种风格是Dave Astels的推广，对我来说，这是TDD的一种新形式，它具有一些重要的好处。 它侧重于行为而不是测试以及小型测试类，试图达到每个规范（测试）方法基本上有一行的程度。 这种风格适合所有级别的测试，可以使用任何现有的单元测试框架完成，尽管较新的框架（xSpec样式）有助于将行为集中在一起而不是测试。

您还可以找到一个有用的BDD组：

http://groups.google.com/group/behaviordrivendevelopment/

测试驱动开发是一种测试优先的软件开发方法，这意味着它需要在编写将要测试的实际代码之前编写测试代码。 在Kent Beck的话中：

这里的样式是编写几行代码，然后是一个应该运行的测试，甚至更好，编写一个不会运行的测试，然后编写将使其运行的代码。

在弄清楚如何编写一小段代码之后，现在，我们希望获得即时反馈并实践“代码一点，测试一点，代码一点，测试一点”。 所以我们马上为它写一个测试。

因此，TDD是一种低级技术方法，程序员可以使用它来生成干净的代码。

行为驱动开发是一种基于TDD创建的方法，但演变为一个不仅仅涉及程序员和测试人员的流程，而是涉及整个团队和所有重要的利益相关者，技术和非技术。 BDD从一些简单的问题开始，TDD没有很好地回答：我应该写多少测试？ 我应该测试什么 - 我不应该做什么？ 我写的哪些测试对业务或产品的整体质量实际上很重要，哪些只是我的过度工程？

如您所见，此类问题需要技术与业务之间的协作。 业务利益相关者和领域专家通常可以告诉工程师哪种测试听起来有用 - 但前提是测试是处理重要业务方面的高级测试。 BDD将此类业务测试称为“示例”，如“告诉我此功能应如何正确运行的示例”，并为低级技术检查（如数据验证或测试API集成）保留“测试”一词。 重要的是，虽然测试只能由程序员和测试人员创建，但是整个交付团队可以收集和分析示例 - 设计人员，分析师等。

在一句话中，到目前为止我发现 BDD的最佳定义之一是BDD与“与领域专家进行对话并使用示例来获得对所需行为的共同理解并发现未知数。”发现部分非常重要。 随着交付团队收集更多示例，他们开始越来越多地了解业务领域，从而减少了他们必须处理的产品的某些方面的不确定性。 随着不确定性的降低，交付团队的创造力和自主性也在增加。 例如，他们现在可以开始建议他们自己的例子，由于他们缺乏技术专长，业务用户认为不可能。

现在，与业务和领域专家进行对话听起来很棒，但我们都知道这通常会在实践中结束。 我以技术作为程序员开始了我的旅程。 作为程序员，我们被教导编写代码算法，设计模式，抽象。 或者，如果您是一名设计师，您将被教导设计 -组织信息并创建漂亮的界面。 但是，当我们获得入门级工作时，我们的雇主希望我们“为客户创造价值”。 在这些客户中，例如......银行。 但除了如何有效降低账户余额之外，我几乎无法了解银行业务。 因此，我必须以某种方式将对我的期望转化为代码...如果我想提供任何价值，我将不得不在银行业务和我的技术专长之间架起一座桥梁。 BDD帮助我在交付团队和领域专家之间建立稳定的流畅沟通基础上建立了这样一座桥梁。

学到更多

如果你想了解更多关于BDD的信息，我写了一本关于这个主题的书。 “编写出色的规范”探讨了分析需求的艺术，并将帮助您学习如何构建出色的BDD流程，并将示例用作该流程的核心部分。 本书讨论了无处不在的语言，收集示例，并从示例中创建所谓的可执行规范（自动化测试），这些技术可帮助BDD团队按时和按预算提供出色的软件。

如果您有兴趣购买“写出优秀的规格”， 您可以使用促销代码39nicieja2 节省39％ :)

我已经用BDD方法进行了一些实验，我的早熟结论是BDD非常适合用例实现，但不适用于底层细节。 TDD仍然在这个水平上徘徊。

BDD也用作通信工具。 目标是编写可由领域专家理解的可执行规范。

行为驱动开发似乎更关注开发人员之间以及开发人员和测试人员之间的交互和沟通。

维基百科文章有一个解释：

行为驱动的发展

虽然不是自己练习BDD。

在我看来，BDD是一个更广泛的范围。 它几乎意味着使用了TDD，BDD是一种包含的方法，它收集信息和使用TDD实践以确保快速反馈的要求。

考虑TDD设计的主要好处。 它应该被称为测试驱动设计。 BDD是TDD的子集，称之为行为驱动设计。

现在考虑一种流行的TDD实现 - 单元测试。 单元测试中的单位通常是一个逻辑，这是您可以做的最小工作单元。

当您以功能性方式将这些单元放在一起来描述机器所需的行为时，您需要了解您对机器描述的行为。 行为驱动设计侧重于验证实施者对用例/要求/无论如何的理解，并验证每个功能的实现。 BDD和TDD通常用于通知设计的重要目的，以及验证实现的正确性的第二个目的，尤其是当它发生变化时。 BDD完成权限涉及biz和dev（和qa），而单元测试（可能被错误地视为TDD而不是一种类型的TDD）通常在dev silo中完成。

我想补充一点，BDD测试可以作为生活需求。

凭借我与BDD相比最新的BDD知识，BDD专注于指定接下来会发生什么，而TDD专注于设置一组条件然后查看输出。

BDD很大程度上是TDD完成的。 但是，BDD提供了额外的价值。 这是一个链接：

BDD不仅仅是“TDD做得对”

这是快照：

• TDD只是在编写代码之前测试代码的过程！

• DDD是在每个触摸代码周期之前被告知域的过程！

• BDD是TDD的一个实现，它引入了DDD的某些方面！

测试驱动开发（TDD）和行为驱动开发（BDD）之间的区别

• BDD侧重于系统的行为方面，而不是
  TDD关注的系统的实现方面。

• BDD更清楚地了解系统应该做什么
  从开发人员和客户的角度来看。 仅限TDD
  让开发人员了解系统应该做什么。

• BDD允许开发人员和客户一起工作以进行系统源代码中包含的需求分析。

简而言之，TDD和BDD之间存在重大差异在TDD中，我们主要关注测试数据在BDD中，我们主要关注项目的行为，以便任何非编程人员能够代表标题理解代码行。那种方法

TDD和BDD之间没有区别。 除了你可以更好地阅读你的测试，你可以使用它们作为要求。 如果您使用与编写BDD测试相同的单词编写您的需求，那么您可以从客户端获取一些已准备好编写代码的测试。