我开始购买 BDD。基本上，据我了解，您编写的场景描述了某个故事的良好接受标准。你从简单的测试开始，从外到内，使用模拟来代替你还没有实现的类。随着你的进步，你应该用真实的类替换模拟。来自Introduction to BDD：
起初，碎片是 使用模拟来设置 帐户是信用卡或信用卡 有效。这些构成了起始 实施行为的要点。作为 你实现应用程序， 给定和结果更改为使用 你的实际课程 实施，以便到时 场景完成后，他们有 成为适当的端到端功能 测试。
我的问题是：当你完成一个场景的实现后，你使用的所有类都应该是真实的吗，就像在集成测试中一样？例如，如果您使用 DB，您的代码是否应该写入真实（但轻量级的内存中）DB？最后，您是否应该在端到端测试中进行任何模拟？
【问题讨论】：
标签： unit-testing tdd mocking bdd
好吧，这取决于:-) 据我了解，BDD 生成的测试仍然是单元测试，因此您应该使用模拟来消除对 DB 等外部因素的依赖。
然而，在完全成熟的集成/功能测试中，您显然应该针对整个生产系统进行测试，而不需要任何模拟。
【讨论】：
集成测试可能包含存根/模拟来伪造您正在集成的模块之外的代码/组件。
但是，恕我直言，端到端测试应该意味着一路上没有存根/模拟，而只是生产代码。或者换句话说 - 如果存在模拟 - 这并不是真正的端到端测试。
【讨论】：
是的，当场景运行时，理想情况下您的所有课程都将是真实的。一个场景从用户的角度来练习行为，所以系统应该是用户所看到的。
在 BDD 的早期，我们通常从场景中的模拟开始。我不再为这个烦恼了，因为随着你的关卡不断地嘲讽是一件很辛苦的事情。相反，如果它能让我更快地从利益相关者那里获得反馈，我有时会做一些硬编码数据或行为之类的事情。
我们仍然在单元测试中保留模拟。
当然，对于数据库之类的东西，您可以使用内存数据库或任何有助于您更快获得反馈的东西。在某些时候，您可能应该在尽可能接近生产的系统上运行您的场景。如果这太慢，您可能会在一夜之间完成，而不是作为常规构建周期的一部分。
至于你“应该”做什么，写正确的代码比写正确的代码要复杂得多。在担心我的环境与生产环境有多接近之前，我担心使用我的场景从利益相关者和用户那里获得反馈。当然，当您达到每两周部署一次更改的地步时，您可能希望更加确定您没有引入任何错误。
祝你好运！
【讨论】：
我同意 Peter 和 ratkok 的观点。我认为你永远保留模拟，所以你总是有单元测试。
另外，额外进行集成测试是合适的（无模拟，使用数据库等）。
您有时甚至会发现中间代码很有用（模拟一段依赖代码 (DOC)，而不是另一段）。
【讨论】：
我最近才开始研究 BDD，尤其是 jBehave。我在相当大的企业工作，有很多瀑布式的、注重仪式的人。我将 BDD 视为一种将业务用例转化为测试的方式，然后开发人员可以将其转化为单元测试或集成测试。
在我看来，BDD 不仅是帮助开发人员了解业务需求的一种方式，也是一种确保尽可能准确地表达这些需求的方式。
我的观点是，如果您正在处理模拟，那么您就是在进行单元测试。您既需要单元测试来测试类操作的细节，又需要集成来测试该类与其他类的兼容性。我发现开发人员经常会在两者之间产生矛盾，但最好尽可能清晰并彼此分开。
【讨论】：