消费端驱动的契约测试
在微服务架构中，通常有许多有不同团队开发的微服务。这些微型服务协同工作来满足业务需求（例如，客户请求），并相互进行同步或异步通信。消费端微服务的集成测试具有挑战性，通常用 TestDouble 以获得更快、更低成本的测试运行。但是 TestDouble 通常并不能代表真正的微服务提供者，而且如果微服务提供者更改了它的 API 或 消息，那么 TestDouble 将无法确认这些。另一种选择是进行端到端测试，尽管它在生产之前是强制性的，但却是脆弱的、缓慢的、昂贵的且不能替代集成测试（Test Pyramid）。
在这方面消费端驱动的契约测试可以帮助我们。在这里，负责消费端微服务的团队针对特定的服务端微服务，编写一套包含了其请求和预期响应（同步）或消息（异步）的测试套件，这些测试套件称为显式的约定。对于微服务服务端，将其消费端所有约定的测试套件都添加到其自动化测试中。当特定服务端微服务的自动化测试执行时，它将一起运行自己的测试和约定的测试并进行验证。通过这种方式，契约测试可以自动的帮助维护微服务通信的完整性。
优点
- 如果提供程序意外更改 API 或消息，可以被快速的自动发现
- 更少意外、更健壮，特别是包含大量微服务的企业应用程序
- 改善团队自主性
缺点
- 需要额外的工作来开发和集成微服务服务端的契约测试，因为他们可能使用完全不同的测试工具
- 如果契约测试与真实服务情况不匹配，将可能导致生产故障
何时使用需求驱动的契约测试
- 在大型企业业务应用程序中，通常由不同的团队开发不同服务
何时不宜使用消费端驱动的契约测试
- 所有微服务由同一团队负责开发的小型简单的应用程序
- 如果服务端微服务是相对稳定的，并且不处在活跃的开发状态
