我开始购买BDD。基本上，据我所知，你写的情景描述了某些故事的良好接受标准。你从简单的测试开始，从外部开始，使用mock代替尚未实现的类。随着你的进步，你应该用真正的课程取代嘲笑。从Introduction to BDD：BDD和功能测试
起初，片段 使用嘲笑设置一个 帐户是信用卡或一卡 有效实施。这些形成了实施行为的起点 。作为 你实现应用程序中， 吉文和成果改为使用 你 实现的实际类，所以由 方案完成时，他们有 成为适当的终端到终端的功能 测试。
我的问题是：当你完成一个场景的实现时，你使用的所有类都应该是真实的，就像在集成测试中一样？例如，如果您使用数据库，您的代码是否应写入真实（但轻量级的内存）数据库？最后，你应该在你的端到端测试中有任何模拟吗？
嗯，它取决于:-)据我所知，由BDD产生的测试仍然是单元测试，因此您应该使用mock来消除对像DB这样的外部因素的依赖。但是，在完全成熟的集成/功能测试中，您显然应该针对整个生产系统进行测试，无需任何嘲讽。
集成测试可能包含存根/模拟以伪造您要集成的模块之外的代码/组件。
但是，恕我直言，端到端测试应该指的是沿途没有存根/模拟，而只是生产代码。或者换句话说 - 如果有嘲笑 - 这不是真正的端到端测试。
我同意彼得和ratkok。我认为你永远保持模拟，所以你总是有单元测试。
另外，还可以另外进行集成测试（无模仿，使用数据库等）。
您甚至可能会发现有时有用（模拟一块依赖代码（DOC），但不是另一个）。
我最近才看到BDD，特别是jBehave。我在有很多瀑布，仪式导向的人的大型企业工作。我将BDD视为一种获取业务用例的方法，然后直接转换为测试，然后开发人员可以将其转变为单元测试或集成测试。
BDD在我看来不仅仅是一种帮助开发人员了解业务需求的方式，还是一种确保尽可能准确表示这些需求的方法。
我认为，如果你正在处理模拟，那么你正在做单元测试。您需要单元测试来测试类操作的细节，并且需要集成来测试该类与其他人的兼容性。我发现开发人员经常在两者之间注入信息，但最好尽可能清楚并保持彼此分开。
是的，在场景运行的时候，理想情况下所有的类都是真实的。一个场景从用户的角度来演示行为，所以系统应该像用户看到的那样。
在BDD的早期，我们习惯于在情景模拟中开始。我不再为此而烦恼，因为在你进入关卡时继续嘲笑很多工作。相反，如果我能够更迅速地从利益相关者那里获得反馈，我有时候会做类似硬编码数据或行为的事情。
虽然我们仍然在单元测试中保持模拟。
对于像数据库这样的东西，当然，您可以使用内存数据库或任何可以帮助您更快获得反馈的内容。在某些情况下，您应该尽可能在接近生产的系统上运行场景。如果这太慢了，你可能会在一夜之间做它，而不是你的常规构建周期的一部分。
至于你“应该”做什么，编写正确的代码比编写正确的代码要困难得多。在担心我的环境与生产环境有多接近之前，我担心使用我的方案从利益相关方和用户那里获得反馈。当你每隔几周就开始部署变更的时候，当然，你可能会更确定你没有引入任何错误。
祝你好运！