BDD和功能测试

Question

我开始接受BDD的理念。基本上，我理解为您编写描述某个故事的验收标准的场景。您从外到内编写简单的测试，使用模拟代替尚未实现的类。随着进展，您应该用真正的类替换模拟。引自BDD介绍：

起初，使用模拟来设置账户余额或验证卡片是否有效等，这些是实现行为的起点。当您实现应用程序时，给定和结果被更改为使用您已经实现的实际类，因此在完成场景时，它们已变成适当的端到端功能测试。

我的问题是：当您完成场景实现时，是否所有使用的类都应该是真实的，就像集成测试一样？例如，如果您使用数据库，您的代码是否应该写入真实（但轻量级的内存）数据库？最终，您的端到端测试中是否应该有任何模拟？

- Dan

Answer 1

好的，这取决于情况 :-) 据我所知，BDD生成的测试仍然是单元测试，因此您应该使用模拟来消除对外部因素（如DB）的依赖。

但是，在完整的集成/功能测试中，您显然应该针对整个生产系统进行测试，而没有任何模拟。

- Péter Török

Answer 2

集成测试可能包含存根/模拟来伪造您正在集成的模块之外的代码/组件。

然而，在我看来，端到端测试应该意味着沿途没有存根/模拟，只有生产代码。换句话说，如果存在模拟，则不是真正的端到端测试。

- ratkok

Answer 3

是的，理想情况下，当场景运行时，所有的类都应该是真实存在的。场景从用户的角度来练习行为，因此系统应该像用户看到的那样。

在BDD早期，我们通常会从场景中开始使用模拟对象。我不再这样做了，因为随着你逐渐深入，保持模拟将需要大量的工作。相反，如果它能让我更快地得到利益相关者的反馈意见，有时我会硬编码数据或行为等。

但我们仍然会在单元测试中使用模拟对象。

对于数据库等事情，当然，你可以使用内存数据库或任何可以帮助你更快地得到反馈的工具。但是，在某些时候，你可能应该在尽可能接近生产环境的系统上运行你的场景。如果这太慢了，你可以选择在晚上运行而不是作为你的常规构建周期的一部分。

至于你应该做什么，写正确的代码比写正确的代码更棘手。在我担心我的场景能否获得利益相关者和用户的反馈之前，我担心环境是否与生产环境接近。当你到达每两周部署一次变更的程度时，你可能需要更多的确定性，以确保你没有引入任何错误。

祝你好运！

- Lunivore

Answer 4

我同意Peter和ratkok的观点。我认为你应该永远保留mocks，这样你就可以始终拥有单元测试。

另外，还应该进行集成测试（不使用mocks，使用数据库等等）。

有时候甚至可能会发现中间状态也很有帮助（mock一个依赖代码（DOC），但不mock另一个）。

- jyoungdev

Answer 5

我最近才开始研究BDD，特别是jBehave。我在相当大的企业中工作，有很多瀑布、仪式导向的人。我正在研究BDD作为一种将业务用例直接转化为开发人员可以转化为单元测试或集成测试的方式。

对我来说，BDD不仅是帮助驱动开发人员理解业务需求的一种方式，而且还是确保这些需求被准确表示的一种方式。

我的观点是，如果你正在处理模拟，则正在进行单元测试。你需要进行单元测试来测试类操作的细节，并进行集成测试以测试该类与其他类的协作情况。我发现开发人员经常混淆两者之间的区别，但最好尽可能清晰，并将它们分开。

- drekka