BDD 被吹捧为“TDD 做得对”。
但是，TDD 广泛用于单元测试，而不是端到端集成测试。
哪种测试最适合 BDD？
【问题讨论】：
标签： unit-testing tdd integration-testing bdd
我会给出我认为最有可能的答案，但我可能会偏离轨道。
TDD 最初是通过单元测试实现的，它通过调用软件的各个组件并期望某些结果来阐明对各个组件的要求。
BDD 只是将相同的概念应用于整个系统。因此，对于 BDD，您编写集成测试，从外向内调用系统，通过模拟鼠标点击等，或最终用户用于访问系统的任何界面。
BDD 似乎实际上是一种黑盒/UAT 测试，因为它关注的是整个系统的行为，而不是实现行为的方式。
因此，编写单元测试和集成测试似乎是可取的，但至少，集成测试，这样如果我们没有时间验证每个组件，我们至少可以验证整个系统。
【讨论】：
基本思想是在代码之前编写测试，因此对于任何功能，使用适当的测试来检查该功能。如果您要添加的功能是“单击报告错误链接应发送电子邮件”，那么集成测试似乎是合适的（可能对该功能的组件进行了一些单元测试）。如果您正在处理的功能是“平均使用量计算应该省略最高和最低值”，那么单元测试可能更合适。重要的是能够准确地判断您正在构建的内容何时完成，然后确保更改不会破坏它。剩下的只是簿记。
【讨论】：
您经常看到在 BDD 周期中使用验收/集成测试的原因是，许多 BDD 从业者非常重视模拟和由外而内的开发。因此，它们往往需要包括端到端集成/验收测试以及单元测试，以确保系统的整体行为。
当在单元测试中使用假对象而不是真实对象作为协作者时，很容易验证被测隔离单元是否以正确的方式运行（即它正确地修改了它的状态，并发送适当的消息）。然而，它只能验证单个对象的行为是否符合预期。因此，需要进行端到端的验收测试，以验证系统中的所有对象在一起使用时是否向最终用户提供了承诺的价值。
所以基本上在这种方法中，单元测试和验收测试扮演以下角色：
单元测试 - 孤立的对象以正确的方式运行
验收/集成测试 - 所有对象共同提供系统的承诺价值。
虽然我本人是这种开发风格的大力支持者，但它在某种程度上独立于一般的 BDD 思想。在我看来，只有当您在单元测试中使用模拟和存根隔离被测系统时，才需要进行验收/集成测试。
【讨论】：
哪种测试（集成测试、单元测试）最适合 BDD？
我会在Behavior-Driven Development with SpecFlow and WatiN 中描述的两个嵌套循环中使用这两个循环
* writing a failing integration tests
* writing a failing unit test as part of the solution of the integration test
* making the unittest pass
* refactor
* writing the next failing unit test as part of the integration test
* unitl the integration test passes
* writing the next failing integration tests
【讨论】：