BDD和功能测试

Question

我开始买入BDD。基本上，正如我所理解的那样，您编写的场景描述了某些故事的良好接受标准。你从简单的测试开始，从外到内，使用模拟代替你尚未实现的类。随着进步，你应该用实际类替换模拟。来自Introduction to BDD：

  

首先，片段是   使用模拟实现设置   帐户是信用卡或卡   有效。这些形成了起点   实施行为的要点。如   你实现了应用程序，   给予和结果改为使用   你拥有的实际课程   实施，以便到时候   情景已经完成，他们有   成为适当的端到端功能   测试

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

Answer 1

嗯，这取决于:-)据我所知，BDD产生的测试仍然是单元测试，所以你应该使用模拟消除对DB等外部因素的依赖。

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

Answer 2

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

然而，恕我直言，端到端测试应该意味着一路上没有存根/模拟，而只是生产代码。或者换句话说 - 如果存在模拟 - 它不是真正的端到端测试。

Answer 3

是的，当一个场景运行时，理想情况下你的所有课程都是真实的。场景从用户的角度来衡量行为，因此系统应该像用户看到的那样。

在BDD的早期，我们过去常常在场景中使用模拟。我不再为此烦恼了，因为当你下到关卡时，继续嘲笑是很多工作。相反，如果能让我更快地从利益相关者那里获得反馈，我有时会做硬编码数据或行为等事情。

我们仍然在单元测试中保持模拟。

对于像数据库这样的东西，当然，您可以使用内存数据库或任何可以帮助您更快地获得反馈的内容。在某些时候，您应该在尽可能接近生产的系统上运行您的方案。如果这太慢，您可能会在一夜之间完成，而不是作为常规构建周期的一部分。

至于你“应该”做什么，编写正确的代码比编写正确的代码要困难得多。在担心环境与生产环境的接近程度之前，我担心使用我的场景来获取利益相关者和用户的反馈。当你到达每两周更新一次的时候，当然，你可能想要更确定你没有引入任何错误。

祝你好运！

Answer 4

我同意Peter和ratkok的观点。我认为你永远保持模拟，所以你总是进行单元测试。

另外，还需要进行集成测试（没有模拟，使用数据库等等）。

您甚至可能会发现中间人有时会有所帮助（模拟一个依赖代码（DOC），而不是另一个代码）。

Answer 5

我最近才开始研究BDD，尤其是jBehave。我在相当大的企业工作，有很多瀑布，仪式导向的人。我正在考虑将BDD作为一种获取业务用例的方法，然后将其直接转换为测试，然后开发人员可以将其转变为单元测试或集成测试。

在我看来，BDD不仅仅是帮助推动开发人员了解业务需求的一种方式，而且还是一种确保这些需求得到准确表达的可行方法。

我的观点是，如果你正在处理模拟，那么你正在进行单元测试。您需要进行单元测试以测试类操作的详细信息，并进行集成以测试该类是否能够与其他人一起运行。我发现开发人员经常在两者之间注入，但最好尽可能清楚并保持彼此分开。