BDD是否可以替代TDD？
2
完全不是。BDD只是TDD的一种变体。
在TDD中，你将你的需求表述为一个可执行的测试，然后编写生产代码来满足测试。BDD则只是重新将这些要求描述为更易于人类阅读的形式，因此使得测试报告对于阅读者而言更加冗长。（顺便说一下：为了实现这一点，BDD需要比传统的数据驱动单元测试更多的代码...）
就是这样。
Thomas
1
在他的 TDD 咨询工作期间，Dan North 发现许多人对“测试”部分感到困惑，因为他们有测试经验，所以他决定更改名称。因此，最初的 BDD 正是 TDD，只是被正确解释了而已。 之后，Dan 开始扩展使用可执行规范（单元测试）来驱动实现的想法，通过添加另一个规范级别来实现。他受到用户故事的启发，因此大多数工具实现的最简单的 BDD 允许您将要求编写为用户故事场景，然后编写生成单元测试的代码，并从这些单元测试中进行实现。因此，与 TDD 相比，现在可以看到还有另一个规范级别 - 用户故事。许多工具包括用户故事到测试的准备转换，因此许多人会忘记它们，但它们仍然存在，并且不能完全省略 - 实际上和理论上都不能。如注释所述，编程用户故事并不高效。但这不是重点，您使用用户故事从利益相关者那里收集要求，并通过执行验收测试来证明已经实现了这些要求。
BDD 中还有许多其他小问题，您最好阅读 Dan 的博客以了解它们，但主要观点是 BDD 是 TDD 的扩展，甚至在实现阶段之外，因此它们不能互换或被彼此视为无用。
Gabriel几乎是正确的。
在单元级别上的根本区别是BDD使用“应该”而不是“测试”这个词。事实证明，当你说“测试”时，大多数人开始考虑他们的代码做了什么以及如何进行测试。通过BDD，我们考虑-并质疑-我们的代码应该做什么。这是一个微妙但重要的观点，如果你想知道为什么它很强大，请阅读神经语言编程-特别是关于单词如何影响思维和世界模型的方式。简单来说，许多新手TDD者开始固定他们的代码，以便没有人能够破坏它。BDDers倾向于提供示例，演示其代码的价值，以便人们可以安全地更改其代码。
Dan意识到，当他与Chris Matts交谈并编写JBehave时，他可以将其提升到场景级别（场景与故事不完全相同）。因为我们已经在单元级别上使用了“应该”，所以用英语写东西是有意义的（例如，我倾向于使用“应该给我”而不是“应该返回”）。验收测试驱动开发-ATDD-已经存在很长时间了，但这是我所知道的第一次将其用英语与业务利益相关者一起编写。
它不仅仅是TDD的替代品。它是一种不同的测试思维方式-非常注重学习，有意发现我们可能认为自己知道该做什么但实际上并不知道的领域，揭示并帮助我们解决无知和误解。它适用于许多层面。Chris Matts的特征注入将其带入了更高级别的空间，一直到项目愿景。
我们仍然在单元级别上编写示例-或者如果你喜欢的话，规格说明-但实际上，它是一个远高于场景甚至更高级别的模式。如果您想了解更多信息，您可能会发现我的博客有用，Dan的博客更好。此外，Chris有一本关于Real Options的漫画书，概述了我提到的一些模式。
BDD应该强调用户角度的行为，非常适合驱动端到端测试，这是一种贫穷人的DSL，用于接受测试驱动开发。它可以补充TDD，但绝对不是替代品。TDD既是设计活动，也是测试活动（设计不良的代码难以测试->单元测试鼓励良好的设计）。BDD与设计无关。它是一种从代码中抽象出来的测试。
实际上，BDD在底层会产生更多的样板代码，因此我更喜欢在普通编程语言中创建内部DSL来驱动我的接受测试。至于单元测试，BDD强调用户角度的行为，因此不应在单元级别使用。
BDD试图弥合业务利益相关者和程序员之间的沟通差距。在某些领域，它可能很有用，例如银行应用程序，其中对诸如利率计算之类的细节的注意力很重要，并且需要来自领域专家的直接输入。在我看来，BDD并不是其信徒所声称的万灵药，只有在有充分理由时才应使用。
就我所了解的，BDD相对于TDD的优势在于：
- 将测试与实现细节解耦。如果您修改了实现但未更改行为，则功能文件不会中断，只有步骤文件会中断。
- 重用现有的测试代码。如果您定义自定义断言、固定装置、帮助程序等，可以通过TDD做到同样的事情。但是我们（至少我）通常会复制粘贴测试代码（不好的习惯）。通过BDD，重用代码要容易得多。仍然会有一些重复，但至少它将在Gherkin中。
其他所有内容都与TDD一样进行。因此，您可以在步骤定义中使用任何断言库，就像在单元测试中使用的那样。唯一的区别是您通过将测试代码中的“什么”（Gherkin中的功能描述）与“如何”（编程语言中的步骤定义）分离来添加了另一个抽象级别。
你可以使用“基于示例的规格描述”这个术语来代表行为驱动开发（BDD），这突出了这种方法的一个重要方面：通过全团队的规格说明研讨会、小型会议或远程审核来协作进行规格说明。在这些不同利益相关者参加的会议中，使用具体的示例来说明需求。以示例形式讨论需求有助于创建问题领域和可能解决方案的共享理解。
意外地，具有示例的规格说明非常适合于测试自动化。因此，您通常可以提高测试覆盖率。但是，这种方法也有助于吸引非技术干系人员参与。帮助您创建业务可读的输入的工具本质上与编程语言无关，而且通常基于简单的文档格式，很容易被许多人理解。
BDD并不是要取代TDD。它是为你的TDD实践提供更多结构和纪律。TDD最困难的事情在于没有全局视野的开发人员几乎不知道该测试什么以及测试多少。BDD为这个灰色区域提供了非常具体的指导方针。请查看这篇文章，
http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/
原文链接