BDD 是 TDD 的替代品吗？
I wonder whether BDD is a replacement of TDD? What I understand now is that in an ultimate BDD we don't have unit tests any more. Instead there are stories/scenarios/features and "test steps". And it looks like a complete replacement of TDD for me. TDD is dead?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
一点也不。 BDD只是TDD的一个变体。
在 TDD 中，您将需求制定为可执行测试，然后编写生产代码来完成测试。 BDD 只是将这些要求重新表述为更易于人类阅读的形式，从而使测试对于查看测试报告的人类读者来说更加冗长。 （顺便说一句：为了实现这一点，BDD 需要比传统的数据驱动单元测试更多的代码......）
仅此而已。
托马斯
Not at all. BDD is just a variant of TDD.
In TDD, you formulate your requirements as an executable test, then write the production code to fulfill the test. BDD does nothing but re-formulate these requirements into a more human-readable form and thus makes the tests somewhat more verbose to a human reader who looks at the test report. (Btw: To achieve this, BDD requires way more code than traditional data-driven unit testing...)
That's all.
Thomas
对此我与其他回答者有不同的看法。
Dan North 在 TDD 咨询工作中创建了 BDD，当时他看到很多人对“测试”部分感到困惑，因为他们有测试经验，他决定更改名称。所以一开始，BDD 正是 TDD，解释得正确。
之后，Dan 开始通过添加另一个级别的规范来扩展使用可执行规范（单元测试）来驱动实现的想法。他受到用户故事的启发，因此大多数工具实现的最简单的 BDD 可以让您将需求编写为用户故事场景，而不是编写生成单元测试的代码，然后根据这些单元测试来实现。现在您会看到，与 TDD 相比，还有另一个级别的规范 - 用户故事。许多工具包括将用户故事准备好翻译为测试，因此许多人像您一样忘记了它们，但它们仍然存在并且不能完全省略 - 实际上和理论上如上所述，对用户故事进行编程效率不高。但这不是重点，您使用用户故事来收集利益相关者的需求，并通过执行验收测试来证明您已实现它们。
BDD还有很多其他的小东西，你最好读一下Dans的博客来理解它们，但要点是，即使在实现阶段之外，BDD也是TDD的扩展，所以它们不能互换或互相变得无用。
I have a different viewpoint on this than other responders.
Dan North created BDD druing his consulting work on TDD when he saw, that many people were confused by the "test" part, because they had testing experience, he decided to change the name. So at first, BDD was exactly what TDD is, explained correctly.
After that Dan started to extend the idea of using executable specifications (unit tests) to drive the implementations by adding another levels of specification. He was inspired by user stories, so the simplest BDD implemented by most tools lets you write requirements as user story scenarios, than you write code which generates unit tests and than from those unit tests you work on implementation. So now you see compared to TDD there is another level of specification - user stories. Many tools include prepared translations of user stories to tests, so many forget about them as you did, but they are still there and cannot be fully omitted - practically and also theoretically as noted, programming user stories is not efficient. But that is not the point, you use user stories to gather requirements from stakeholders and to proove you implemented them by executing acceptance tests.
There are many other small things in BDD, you better read Dans blog to understand them, but the main point is that BDD is an extension of TDD even outside the implementation phase, so they cannot be interchanged or rendered useless by each other.
加布里埃尔几乎是对的。
单元级别的根本区别在于 BDD 使用“应该”一词而不是“测试”。事实证明，当你说“测试”时，大多数人开始思考他们的代码做了什么，以及如何测试它。通过 BDD，我们考虑并质疑我们的代码应该做什么。这是一个微妙但重要的观点，如果你想知道为什么它很强大，请阅读《神经语言编程》——特别是关于单词影响思想和世界模型的方式。举一个简单的例子，许多 TDD 新手开始固定他们的代码，这样就没有人可以破坏它。 BDD 者倾向于提供示例来证明其代码的价值，以便人们可以安全地更改其代码。
Dan 在与 Chris Matts 交谈并撰写 JBehave 时意识到，他可以将其提升到场景级别（场景与故事并不完全相同）。因为我们已经在单元级别使用“应该”，所以开始用英语编写内容是有意义的（例如，我倾向于使用“应该给我”而不是“应该返回”）。验收测试驱动开发 - ATDD - 已经存在很长时间了，但据我所知，这是第一次有人用英语编写并涉及业务利益相关者。
它不仅仅是 TDD 的替代品。这是一种不同的测试思考方式——非常注重学习，故意发现我们可能认为自己知道自己在做什么但实际上并不知道的领域，发现并帮助我们解决无知和误解。它在很多层面上发挥作用。 Chris Matts 的功能注入将其带入更高层次的空间，一直到项目愿景。
我们仍然会在单元级别编写示例（或者规范，如果您愿意的话），但实际上，这是一种远远高于场景的模式。如果您想了解更多信息，可能会发现我的博客很有用，丹的更好。另外，克里斯有一本关于实物期权的漫画书< /a> 概述了我提到的一些模式。
Gabriel is almost right.
The fundamental difference at a unit level is that BDD uses the word "should" instead of "test". It turns out that when you say "test", most people start thinking about what their code does, and how they can test it. With BDD, we consider - and question - what our code should do. It's a subtle but important point, and if you want to know why that's powerful, go read up on Neuro-linguistic Programming - particularly around the way in which words affect thoughts and the model of the world. As a brief example, many people who are new to TDD start pinning their code down so that nobody can break it. BDDers tend to provide examples which demonstrate the value of their code so that people can change their code safely.
Dan realised while he was talking with Chris Matts and writing JBehave that he could take this up to a scenario level (scenarios aren't quite the same as stories). Because we were already using "should" at a unit level, it made sense to start writing things in English (I tend to use "should give me" rather than "should return", for instance). Acceptance Test Driven Development - ATDD - has been around for a long time, but this was AFAIK the first time anyone had written them in English with business stakeholders involved.
It's more than just a replacement for TDD. It's a different way of thinking about testing - very much focused on learning, deliberately discovering areas where we perhaps thought we knew what we were doing but didn't, uncovering and helping us to resolve ignorance and misunderstanding. It works at many levels. Chris Matts' Feature Injection takes this into the higher level space, right the way up to project visioning.
We still do write examples - or specifications if you like - at a unit level too, but really, it's a pattern which goes far higher than even scenarios. If you want to know more you might find my blog useful, Dan's is even better. Also, Chris has a comic book on Real Options which outlines some of the patterns I've mentioned.
BDD 并不是要取代 TDD。它是为您的 TDD 实践提供更多的结构和规则。 TDD 最困难的事情是，没有大局观的开发人员几乎不知道要测试什么以及测试多少。 BDD 为这个灰色区域提供了非常具体的指导方针。查看这篇文章，
http://codingcraft.wordpress .com/2011/11/12/bdd-get-your-tdd-right/
BDD is not about replacing TDD. It is about giving some more structure and deciplene to your TDD practices. The hardest thing about TDD is that developers without the bigger picture hardly have clue on what to test and how much to test. BDD provides a very concrete guideline with this gray area. Check out this post,
http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/
据我了解，BDD 相对于 TDD 的优点是：
其他一切都与 TDD 的正常情况相同。因此，您可以在单元测试中使用的步骤定义中使用任何断言库。唯一的区别是您通过将测试代码中的内容（小黄瓜中的功能描述）与方式（编程语言中的步骤定义）分开来添加另一个抽象级别。
As far as I understand the advantages of BDD over TDD are:
Everything else goes the same way as normally by TDD. So you can use any assertion lib in the step definitions you would use in the unit tests. The only difference that you added another abstraction level by separating what (feature description in gherkin) from how (step definitions in a programming language) in your testing code.
您可以对 BDD 使用术语“示例规范”，它强调了此方法的一个重要方面：协作指定 - 通过全团队规范研讨会、小型会议或电话会议审查。在与不同利益相关者的这些会议中，使用具体示例来说明需求。以示例的形式讨论需求有助于形成对问题领域和可能的解决方案的共同理解。
意外的是，带有示例的规范非常适合测试自动化。因此，您通常会提高测试覆盖率。但这种方法也有助于让非技术利益相关者参与。这些工具可帮助您创建业务可读输入 本质上与编程语言无关，但通常基于许多人易于理解的简单文档格式人们。
You can use the term "Specification by Example" for BDD, which emphasis an important aspect of this methodology: Specifying collaboratively - through all-team specification workshops, smaller meetings or teleconference reviews. Within these sessions with different stakeholders, concrete examples are used to illustrate requirements. Discussing requirements in the form of examples helps to create a shared understanding of the problem domain and possible solutions.
By accident specifications with examples are well suited for test automation. As a result you usually improve test coverage. But this methodology also helps to involve non-technical stakeholders. The tools that help you create business readable input are by nature not related to programming languages, but often based on simple document formats that are easily understandable by many people.
BDD 应该强调从用户角度的行为，并且非常适合驱动端到端测试，这是一种用于验收测试驱动开发的穷人的 DSL。它可以补充 TDD，但绝对不能替代。 TDD 既是一种设计活动，也是一种测试活动（设计不佳的代码很难测试 -> 单元测试鼓励良好的设计）。 BDD 与设计无关。这是一种完全从代码中抽象出来的测试。
在实践中，BDD 会比正常的验收测试产生更多的样板代码，因此我更喜欢用正常的编程语言创建内部 DSL 来驱动我的验收测试。对于单元测试，BDD 强调从用户角度的行为，因此不应该在单元级别使用。
BDD 试图弥合业务利益相关者和程序员之间的沟通差距。在某些领域，它可能很有用，例如银行应用程序，其中对利率计算等细节的关注非常重要，并且需要领域专家的直接输入。恕我直言，BDD 并不是它的一些追随者声称的万能药，并且只有在有令人信服的理由时才应该使用。
BDD should emphasize behavior from a user perspective and is ideally suited to drive end-to-end tests, a kind of poor man's DSL for acceptance test driven development. It can complement TDD but it definitely is not a substitute. TDD is as much a design activity as it is a testing activity (Code that is poorly designed is difficult to test -> unit tests encourage good design). BDD has nothing to do with design. It is a kind of testing that abstracts away from the code altogether.
In practice BDD results in a lot more boiler-plate code under the hood than normal acceptance tests, therefore I prefer creating an internal DSL in a normal programming language to drive my acceptance tests. As for unit tests, BDD emphasizes behavior from a user perspective and therefore should not be used at the unit level.
BDD is an attempt to bridge the communication gap between business stake holders and programmers. In some areas it can be useful, such as banking applications where attention to detail on things like interest rate calculations is important, and requires direct input from domain experts. IMHO BDD is not the panacea that some of it's acolytes claim it is and should only be used if there is a compelling reason to do so.