lastminute.com采用契约测试来降低系统级集成测试所带来的复杂性，并改进反馈周期和开发过程。eBay 也采用契约测试来帮助其内部进行API演化，并为客户端团队提供支持。
在分布式系统（如微服务架构）中，应用程序服务使用 RPC（远程过程调用）风格的请求或异步消息进行交互。测试这类系统的常用方法是使用系统测试（端到端集成测试），这通常需要将整个系统部署在测试环境中。
lastminute.com 的软件工程师Ivan Dell'Oro指出集成/系统测试所带来的挑战：
eBay 团队也表示：
这两个团队都一直在寻找能够让测试变得不那么脆弱和更快速的方法，目标是改善开发人员/测试人员的体验，缩短反馈周期，加快价值交付的速度，同时支持内部契约的演进，例如 API 规范和消息 schema。
最后，经过一些研究和实验，他们采用契约测试作为验证服务间交互正确性的主要方法。lastminute.com 发现，这给他们的微服务架构和交付过程带来了积极的影响，与标准的系统级测试相比，测试执行时间大大缩短了。eBay 使用契约测试来验证其平台中的集成点，支持通过写作来确保内部 API 可以在不出现不兼容问题的情况下演进。
lastminute.com 已经使用（一个客户端驱动的契约测试工具）对微服务之间的 RPC 交互进行了契约测试，并在随后将其扩展到服务间的异步交互（通过 RabbitMQ 代理交换消息）上。
图片来源：的团队研究了基于规范的 API 定义语义版本控制，但得出的结论是，版本控制本身不足以解决系统测试的脆弱性。他们将（行为驱动开发）视为描述 API 消费者需求的一种方式，生产者和消费者团队协作编写所有需求并使其可执行。事实证明，在采用这种方法时，API 提供方需要在客户需求发生变化时捕获和更新客户需求，而这已被证明是有问题的。
最后，他们发现了契约测试，生产者和消费者团队可以在他们的测试用例中使用 Mock（或存根）来独立地维护测试套件。
他们对Spring Cloud Contract和 Pact 进行了评估，最终选择了后者，因为后者可以更直接地使用 schema，并有更好的跨团队交互支持。他们对 Spring Cloud Contract 和 Pact 进行了评估，最终选择了后者，因为后者可以更直接地使用 schema，并有更好的跨团队交互支持。他们对（一款商业版 Pact 产品）和内部 CI/CD 工具进行了无缝集成，并创建了一个专门的开发者门户，用于配置新的契约测试。
图片来源：强调，契约测试本身并不能完全替代系统级集成测试。契约测试旨在验证服务之间数据交换的正确性，但服务级集成测试会同时执行业务逻辑和错误处理，确保整个流程/数据流的正确性和弹性。
查看英文原文 ：延伸阅读：
测试驱动开发？还是测试驱动需求？
软件界旷世之架：测试驱动开发（TDD）之争
