浅谈契约测试

背景

在现代的开发模式中，基于微服务的开发模式越来越常见，但是随着项目规模的扩大，服务与服务之间的依赖越来越密切，当不同的开发团队去开发不同的服务时，服务的提供者的变动会影响到众多消费它的消费者，为了保证系统的正确性和一致性，这将需要大量的沟通成本和代码修改的时间成本。

之前遇到的某个客户内部就是因为服务与服务之间依赖过多，且存在各种的物理依赖，再加上其他种种原因，使得在集成测试时bug激增。对于他们而言集成测试需要依赖于各个服务版本的一致性以及真实的物理环境，因此他们的集成测试通常需要用上几个小时才可以完成，这就使得整体的效率大大缩减。除此之外，在集成测试中发现的问题也会使得他们花很长的时间去定位到问题所在。

相似的问题在平时的开发过程中也是经常遇到，由于依赖方的接口变更导致在系统集成时频频出错，整体的代码又不得不再加修改，这就使得开发的进度迟迟无法向前推进。

为了解决这类的问题，契约测试应运而生。契约测试不是一个新鲜东西，但在实际项目经历中发现用好契约测试真的会大大增强开发的效率，因此写下这篇文章来简单总结一下契约测试的一些内容。

首先什么是契约测试

契约测试是一个为确保两个独立的系统或者微服务能够兼容并可以相互通信的一个方法，契约测试分为两种，一种是服务提供者驱动的，另一种是消费者驱动的。如下图所示，左侧是一个服务的消费者，右侧是一个服务提供者，消费者调用提供者的接口并消费数据的交互过程会被记录成一份契约，在契约中包含了服务的提供者和消费者是谁，以及消费者对服务的提供者的期望（如请求的参数和返回的结果）。服务的提供者会根据这份契约去反复验证自己是否能够满足消费者的需求，这也就是所