目前，我正在更深入地研究测试技术，尽管我不确定我是否仍然居住在 unittest-land 或者已经将它留在了集成测试领域。
让我详细说明一下，给定两个组件 A 和 B 并且 A 使用 B，那么我们对 B 有一定的“向上合同”，对于 A 有一定的“向下合同”。基本上这意味着：如果 A 使用B 正确且 B 行为正确，则两个合同都将得到履行，一切都会正常工作。
我认为模拟是一种保证给定测试用例所需的向上契约子集的方法。例如，如果数据记录已被较早插入，则数据库连接可能具有检索数据记录的向上合同。数据库连接模拟保证返回某些记录，而不需要将它们插入数据库。
但是，我目前想知道是否也有办法验证向下合约。给定数据库连接的示例，向下契约可能是：您必须连接到数据库并确保连接存在且有效，并输入正确的 SQL 查询。
有人这样做吗？这值得为更复杂的合同工作吗？ （例如，数据库连接可能需要 SQL 解析器才能完全验证对数据库层的调用）
你好，你好
【问题讨论】：
这确实是difference between mocks and stubs - 模拟完全验证了这一点（或者至少可以这样做 - 您可以将模拟用作大多数框架的存根）。从本质上讲，模拟允许您进行协议测试，而不仅仅是“如果你调用 X，我会给你 Y”。我使用的每个模拟框架都可以让您轻松验证诸如“所有这些调用都已进行”和“这些调用以特定顺序发生”之类的事情。
您在组件之间执行的协议越多，测试就越脆弱 - 有时这是完全合适的（例如，“您必须在执行任何其他操作之前验证 ” ) 但很容易导致每次更改实现时都必须更改测试，即使以合理的方式。
【讨论】：
有人这样做吗？
是的，我有时会使用模拟来验证“向下合约”。
例如您可以使用数据库模拟来检查，如果正确 用于登录的凭据。 特别是，如果您有与其他子系统的接口， 然后您可以模拟它们并让模型检查使用情况 违规行为。
例如如果子系统需要初始化 打电话或某种注册，然后你的模型 子系统接口也可以强制执行此操作。
这项工作值得吗？
这取决于你希望你的测试有多深，让我给你一些不同“深度”的例子：
结论：
如果合适，应该这样做。但是，您不能指望模型能够找到界面的每一个错误使用。例如。数据库模型几乎无法检测到两个并发事务是否会导致死锁。
【讨论】：