Question

测试驱动开发在过去几年中一直是.NET社区的风靡一时。最近，我听到了ALT.NET社区关于BDD的抱怨。它是什么？是什么让它与TDD不同？

Answer 1

我理解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。你会在他的Introducing BDD文章中找到一个很好的介绍。

您将在此video中找到BDD和TDD的比较。还有一个关于BDD的评论是Jeremy D. Miller

的“TDD做得对”

2013年3月25日更新

上面的视频已经缺失了一段时间。这是Llewellyn Falco最近的一篇BDD vs TDD (explained)。我发现他的解释清楚明了。

Answer 2

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

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

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

Answer 3

似乎有两种类型的BDD。

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

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

还有一个您可能觉得有用的BDD小组：

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

Answer 4

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

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

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

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

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

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

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

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

了解详情

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

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

Answer 5

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

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

Answer 6

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

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

Behavior-driven development

不是自己练习BDD。

Answer 7

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

Answer 8

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

Answer 9

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

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

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

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

Answer 10

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

BDD is more than “TDD done right”

Answer 11

这是快照：

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



DDD是在每次触摸代码之前获知域名的过程！



BDD是TDD的一个实现，它带来了DDD的某些方面！

希望有所帮助！

Answer 12

测试驱动开发（TDD）与行为驱动开发（BDD）之间的差异

BDD侧重于系统的行为方面，而不是 TDD关注的系统的实施方面。
BDD更清楚地了解系统应该做什么从开发人员和客户的角度来看。 TDD只有让开发人员了解系统应该做什么。
BDD允许开发人员和客户一起工作需求分析包含在源代码中系统

Answer 13

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

Answer 14

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

TDD和BDD之间的主要区别是什么？

14 个答案: