我想知道BDD 是不是TDD 的替代品？我现在明白的是，在最终的 BDD 中，我们不再有单元测试。取而代之的是故事/场景/功能和“测试步骤”。对我来说，它看起来像是 TDD 的完全替代品。 TDD 死了吗？
【问题讨论】：
标签： unit-testing tdd bdd
一点也不。 BDD 只是 TDD 的一种变体。
在 TDD 中，您将需求表述为可执行测试，然后编写生产代码来完成测试。 BDD 只是将这些要求重新表述为更易于阅读的形式，从而使测试对于查看测试报告的人类读者来说更加冗长。 （顺便说一句：要实现这一点，BDD 需要比传统的数据驱动单元测试更多的代码......）
就是这样。
托马斯
【讨论】：
我对此的看法与其他响应者不同。
Dan North 在从事 TDD 咨询工作时创建了 BDD，当他看到很多人对“测试”部分感到困惑时，因为他们有测试经验，他决定改名。所以一开始，BDD 就是 TDD，解释正确。 在那之后，Dan 开始扩展使用可执行规范（单元测试）的想法，通过添加另一个级别的规范来驱动实现。他受到用户故事的启发，因此大多数工具实现的最简单的 BDD 让您可以将需求编写为用户故事场景，而不是编写生成单元测试的代码，而不是从那些单元测试中进行实现。所以现在你看到与 TDD 相比，还有另一个级别的规范——用户故事。许多工具包括将用户故事准备好翻译成测试，所以很多人像您一样忘记了它们，但它们仍然存在并且不能完全省略 - 正如所指出的，实际上和理论上，编程用户故事效率不高。但这不是重点，您可以使用用户故事从利益相关者那里收集需求，并通过执行验收测试来证明您实现了这些需求。
BDD还有很多其他的小东西，你最好阅读Dans的博客来了解它们，但重点是BDD即使在实现阶段之外也是TDD的扩展，所以它们不能相互互换或变得无用.
【讨论】：
加布里埃尔几乎是对的。
单元级别的根本区别在于 BDD 使用“应该”一词而不是“测试”。事实证明，当你说“测试”时，大多数人开始思考他们的代码做了什么，以及如何测试它。对于 BDD，我们考虑并质疑我们的代码应该做什么。这是一个微妙但重要的观点，如果你想知道它为什么如此强大，请阅读神经语言编程——尤其是关于单词影响思想和世界模型的方式。举个简单的例子，许多刚接触 TDD 的人开始固定他们的代码，以便没有人可以破坏它。 BDDers 倾向于提供示例来展示其代码的价值，以便人们可以安全地更改其代码。
Dan 在与 Chris Matts 交谈并编写 JBehave 时意识到，他可以将此提升到场景级别（场景与故事并不完全相同）。因为我们已经在单元级别使用了“should”，所以开始用英语写东西是有意义的（例如，我倾向于使用“should give me”而不是“should return”）。验收测试驱动开发 - ATDD - 已经存在了很长时间，但这是 AFAIK 第一次有人用英语编写它们并涉及业务利益相关者。
它不仅仅是 TDD 的替代品。这是一种不同的测试思维方式——非常专注于学习，有意识地发现我们可能认为我们知道自己在做什么但不知道的领域，发现并帮助我们解决无知和误解。它适用于许多层面。 Chris Matts 的特征注入将其带入了更高层次的空间，直通项目愿景。
我们仍然会在单元级别编写示例 - 或规范，如果您愿意的话，但实际上，这是一种比场景更高级的模式。如果你想知道更多你might find my blog useful，Dan's is even better。另外，Chris has a comic book on Real Options 概述了我提到的一些模式。
【讨论】：
BDD 并不是要取代 TDD。它是关于为您的 TDD 实践提供更多结构和规范。 TDD 最困难的事情是，没有大局的开发人员几乎不知道要测试什么以及要测试多少。 BDD 为这个灰色区域提供了一个非常具体的指导方针。看看这篇文章，
http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/
【讨论】：
据我了解，BDD 相对于 TDD 的优势是：
其他的一切都和 TDD 一样。因此，您可以在单元测试中使用的步骤定义中使用任何断言库。唯一的区别是您通过将测试代码中的内容（小黄瓜中的功能描述）与方式（编程语言中的步骤定义）分开来添加另一个抽象级别。
【讨论】：
您可以使用术语“Specification by Example”来表示 BDD，它强调了此方法的一个重要方面：协作指定 - 通过所有团队的规范研讨会、小型会议或电话会议审查。在与不同利益相关者的这些会议中，使用具体示例来说明需求。以示例的形式讨论需求有助于建立对问题领域和可能解决方案的共同理解。
附带示例的规范非常适合测试自动化。因此，您通常会提高测试覆盖率。但这种方法也有助于involve non-technical stakeholders。 create business readable input 帮助您的工具本质上与编程语言无关，但通常基于许多人容易理解的 simple document formats。
【讨论】：
BDD 应该从用户的角度强调行为，并且非常适合驱动端到端测试，这是一种用于验收测试驱动开发的穷人 DSL。它可以补充 TDD，但绝对不是替代品。 TDD 既是一项测试活动，也是一项设计活动（设计不佳的代码难以测试 -> 单元测试鼓励良好的设计）。 BDD 与设计无关。这是一种完全从代码中抽象出来的测试。
在实践中，BDD 会产生比普通验收测试更多的样板代码，因此我更喜欢使用普通编程语言创建内部 DSL 来驱动我的验收测试。至于单元测试，BDD 强调从用户角度出发的行为，因此不应该在单元级别使用。
BDD 试图弥合业务利益相关者和程序员之间的沟通鸿沟。在某些领域，它可能很有用，例如银行应用程序，其中关注利率计算等细节很重要，并且需要领域专家的直接输入。恕我直言，BDD 并不是它的一些追随者所声称的灵丹妙药，而且只有在有令人信服的理由时才应该使用它。
【讨论】：