BDD应该通过单元测试，集成测试或两者自动化吗？

Question

BDD被吹捧为“TDD做对了”。

然而，TDD广泛用于单元测试，而非端到端集成测试。

哪种测试最适合BDD？

• 我们应该只编写集成测试吗？
• 我们还应该编写单元测试吗？
  • 如果是，每个方案应该有多个单元测试吗？
  • 单元测试涵盖多个场景？在使用MSpec等测试框架时，有没有办法构建这些测试？

Answer 1

  

哪种测试（集成测试，单元测试）最适合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

Answer 2

您经常看到BDD周期中使用的接受/集成测试的原因是因为许多从业者非常重视模拟和外部开发。因此，他们倾向于包括端到端集成/验收测试以及单元测试，以确保系统的总体行为。

当假对象在单元测试中被用作协作者而不是真实对象时，很容易验证被测隔离单元是否以正确的方式运行（即它正确地修改了它的状态，并发送适当的消息）。但是，除了隔离单个对象的行为与预期之外，它无法验证任何内容。因此，必须进行端到端验收测试，以验证系统中的所有对象在一起使用时是否为最终用户提供了承诺的值。

因此，基本上在这种方法中，单元测试和验收测试起到以下作用：

单元测试 - 隔离的对象以正确的方式运行

验收/集成测试 - 所有对象一起提供系统的承诺价值。

虽然我自己是这种发展方式的大力支持者，但它有点独立于一般的BDD思想。在我看来，只有在单元测试中使用模拟和存根隔离被测系统时才需要接受/集成测试。

Answer 3

我会给出最有可能给我的答案，但我可能会偏离这里。

TDD最初是通过单元测试实现的，它通过调用软件并期望某些结果来阐明软件各个组件的要求。

BDD只是将相同的概念应用于整个系统。因此，对于BDD，您可以编写集成测试，通过模拟鼠标点击等从内到外调用系统，或者最终用户用于访问系统的任何接口。

BDD似乎实际上是一种黑盒/ UAT测试，因为它关注整个系统的行为，而不是实现行为的方式。

因此，编写单元测试和集成测试似乎是可取的，但至少是集成测试，因此如果我们没有时间验证每个组件，我们至少可以验证整个系统。 / p>

Answer 4

基本思想是在代码之前编写测试，因此对于任何功能，请使用适当的测试来检查功能。如果您要添加的功能是“单击报告错误链接应该发送电子邮件”，那么集成测试似乎是合适的（可能是对该功能的组件进行了一些单元测试）。如果您正在使用的功能是“平均使用量计算应省略最高值和最低值”，则单元测试可能更合适。重要的是能够准确地判断您正在构建的内容何时完成，以后确保更改不会破坏它。其余的只是簿记。