有时与外部系统或您自己的子系统的通信根本不再有效。由于越来越多的用例如果没有跨系统边界的通信就无法正常运行，因此开发人员必须加班才能使界面重新启动并运行。
集成测试是一种经常使用但仅部分成功的降低接口无法运行风险的方法。每个接口合作伙伴都提供一个测试系统，然后可用于（希望是自动化的）测试。不幸的是，这样的系统并不容易使用。它们需要与生产系统类似的维护工作。这种维护工作常常成为“更重要”任务的牺牲品，这意味着集成测试不能稳定运行，从而失去意义。此外，每个集成测试都需要一定量的数据，因此需要一个复杂的概念来为系统加载数据。
如果你想实践持续交付，集成测试实际上是一个明显的障碍，因为这样你就假设自动化测试是在每个新功能实现后进行的。只有当这些成功时，新版本的软件才能准备好交付。对于每个功能，都必须有一个具有正确数据集的 outlook 电子邮件列表 自动化、隔离的测试系统可用于集成测试，而且这些测试也是自动化的。即使使用 Docker 这样的容器管理系统也很难处理。
如果我们现在想到一个由大量相互通信的小服务定义的微服务环境，我们就已经到了地狱。一旦到达这里，您要么必须在集成测试上投入大量精力，要么完全不进行集成测试。
消费者驱动的合同
所谓的契约测试是逃避集成地狱的一种方法。消费者和提供者只需针对接口契约进行测试，而不是每个用户（消费者）在集成环境中针对其提供者（提供者）进行测试（具有上面列出的所有缺点）。
每个接口都隐式地代表了提供者和消费者之间的契约，如果这种契约被破坏，例如提供者做出不向后兼容的更改，通信将不再有效。
如果这些合同明确作为文档提供，则消费者和提供者可以使用它们来验证各自的接口端（更多内容请参见“合同测试”部分）。
但为什么这些合约应该是“消费者驱动的”，即由用户驱动而不是由提供商驱动？背景很简单：提供商应该只提供至少一个消费者所需的接口。通过消费者合同，消费者定义他们需要哪些，因此供应商必须提供哪些。这些是与提供商和其他消费者协商后定义的。例如，可以标准化类似的接口。接口更改后，消费者可以针对其消费者合约运行测试，并且根据任何失败的测试，立即知道更改是否以及对哪些消费者产生影响。
下图说明了职责。消费者与提供者和其他消费者协调管理和维护合同。然后，两者都在合同测试中验证其接口一侧。