BDD 是否应该通过单元测试、集成测试或两者来实现自动化？

Question

BDD 被誉为“TDD 做得对”。

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

哪种测试最适合 BDD？

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

Answer 1

哪种测试（集成测试、单元测试）最适合 BDD？

我将在两个嵌套循环中使用两者，如 使用 SpecFlow 和 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 测试，因为它关注的是整个系统的行为，而不是实现该行为的方式。

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

Answer 4

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