BDD是TDD的替代品吗？

Question

我想知道BDD是否取代TDD？我现在理解的是，在最终的BDD中，我们不再进行单元测试了。相反，有故事/情景/功能和“测试步骤”。它看起来像是我完全取代TDD。 TDD已经死了？

Answer 1

完全没有。 BDD只是TDD的变种。

在TDD中，您将需求表示为可执行测试，然后编写生产代码以完成测试。 BDD除了将这些要求重新制定为更易于阅读的形式之外什么都不做，因此对于查看测试报告的人类读者而言，测试更加冗长。 （顺便说一句：要实现这一点，BDD需要比传统的数据驱动单元测试更多的代码......）

就是这样。

托马斯

Answer 2

我对此有不同的看法。

Dan North创建了BDD，他在TDD的咨询工作中看到，许多人对“测试”部分感到困惑，因为他们有测试经验，他决定更改名称。所以首先，BDD正是TDD的正确解释。 之后，Dan开始扩展使用可执行规范（单元测试）的想法，通过添加另一级规范来驱动实现。他受到用户故事的启发，因此大多数工具实现的最简单的BDD允许您编写需求作为用户故事场景，而不是编写生成单元测试的代码，而不是您从事实现的单元测试。所以现在你看到与TDD相比，还有另一个规范级别 - 用户故事。许多工具包括准备好的用户故事到测试的翻译，所以很多人忘记了它们，但是它们仍然存在并且不能完全省略 - 实际上并且理论上如所指出的，编程用户故事效率不高。但这不是重点，您可以使用用户故事从利益相关者那里收集需求，并通过执行验收测试来实现它们。

BDD还有很多其他的小东西，你最好阅读Dans博客来理解它们，但重点是BDD是TDD的扩展，甚至在实施阶段之外，所以它们不能相互交换或变得无用。

Answer 3

加布里埃尔几乎是对的。

单位级别的根本区别在于BDD使用“应该”而不是“测试”。事实证明，当你说“测试”时，大多数人开始考虑他们的代码做了什么，以及他们如何测试它。使用BDD，我们会考虑 - 并且质疑 - 我们的代码应该做什么。这是一个微妙但重要的观点，如果你想知道为什么那么强大，请阅读神经语言程序设计 - 特别是在词语影响思想和世界模型的方式。作为一个简单的例子，许多刚接触TDD的人开始将代码固定下来，以便没有人可以破解它。 BDDers倾向于提供示例，证明其代码的价值，以便人们可以安全地更改代码。

Dan在与Chris Matts谈话并写JBehave时意识到他可以将其提升到场景级别（场景与故事不完全相同）。因为我们已经在单位级别使用“应该”，所以开始用英语写东西是有意义的（例如，我倾向于使用“应该给我”而不是“应该返回”）。验收测试驱动开发--ATDD - 已经存在了很长时间，但这是AFAIK第一次有人用英语与业务利益相关者一起编写它们。

它不仅仅是TDD的替代品。这是一种考虑测试的不同方式 - 非常注重学习，故意发现我们可能认为我们知道自己在做什么但没有做到的领域，揭露并帮助我们解决无知和误解。它在许多层面都有效。 Chris Matts的特征注入将其带入更高层次的空间，直至项目愿景。

我们仍然会在单元级别上编写示例 - 或规范（如果您愿意），但实际上，这种模式远远高于甚至情景。如果您想了解更多might find my blog useful，Dan's is even better。另外，Chris has a comic book on Real Options概述了我提到的一些模式。

Answer 4

BDD不是要取代TDD。它是为您的TDD实践提供更多的结构和解密。关于TDD最难的事情是没有更大图片的开发人员几乎不知道要测试什么和测试多少。 BDD为这个灰色区域提供了一个非常具体的指导方针。看看这篇文章，

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 5

据我所知，BDD优于TDD的优点是：

• 将测试与实现细节分离。因此，如果您修改实现，而不是行为，则功能文件不会中断，只是步骤文件。
• 重用现有的测试代码。如果你定义自定义断言，固定装置，助手等，你可以通过TDD做同样的事情......但是我们（至少我）通常会复制粘贴测试代码（坏习惯）。通过BDD重用代码要容易得多。仍然会有一些重复，但至少它会是小黄瓜。

其他一切与TDD正常情况相同。因此，您可以在单元测试中使用的步骤定义中使用任何断言lib。通过将测试代码中的内容（小黄瓜中的特征描述）与编程语言中的步骤定义分开来添加另一个抽象级别的唯一区别。

Answer 6

您可以对BDD使用术语“Specification by Example”，这强调了此方法的一个重要方面：协作指定 - 通过所有团队规范研讨会，小型会议或电话会议评论。在与不同利益相关者的这些会议中，使用具体示例来说明需求。以示例的形式讨论需求有助于创建对问题域和可能解决方案的共同理解。

事故规范与示例非常适合测试自动化。因此，您通常可以提高测试覆盖率。但这种方法也有助于involve non-technical stakeholders。帮助您create business readable input的工具本质上与编程语言无关，但通常基于simple document formats，很多人都能轻易理解。

Answer 7

BDD应该从用户的角度强调行为，非常适合推动端到端测试，这是一种用于验收测试驱动开发的穷人DSL。它可以补充TDD但它绝对不是替代品。 TDD既是一项设计活动，也是一项测试活动（设计不良的代码难以测试 - >单元测试鼓励良好的设计）。 BDD与设计无关。它是一种完全从代码中抽象出来的测试。

在实践中，BDD导致的锅炉板代码比正常的验收测试更多，因此我更喜欢用普通的编程语言创建内部DSL来推动我的验收测试。至于单元测试，BDD从用户角度强调行为，因此不应在单元级别使用。

BDD试图弥合商业利益相关者和程序员之间的沟通差距。在某些领域，它可能很有用，例如银行应用程序，其中对诸如利率计算之类的事情的细节的关注是重要的，并且需要来自领域专家的直接输入。恕我直言BDD并不是它的一些助手声称它的灵丹妙药，只有在有令人信服的理由这样做的情况下才能使用它。