为什么要使用契约测试（Pact）

目前开发过程中存在的问题
联调成本过高,要双方开发到某一阶段后放在同一个环境上才能进行，要同时把握双方的进度，造成资源和时间上的浪费。
对于接口的变动把控相当困难。由于接口变动是普遍存在的，尤其对于调用关系复杂的接口，一旦发生变动，如果没有一套机制进行控制，验证的成本巨大。更不必说持续集成了，只能成为空谈。
契约测试能给我们带来什么
通过使用契约测试，接口调用双方协商接口后就可以并行开发，并且在开发过程中就利用契约进行预集成测试，不用等到联调再来集成拉通接口，一旦成熟，在保证质量的前提下，联调的成本可以减低到几乎为0。
因为契约的存在，让接口的变动有迹可循，即使变动也可以确保变动的安全性和准确性。
与CI的集成是这一整套流程的关键，我们在构建的过程中来完成接口的联调测试，接口变动的验证测试。如果规范整个的开发流程，正确使用契约测试，就可以真正实现持续集成，来达到任何时候构建出来的程序都是真正可发布的状态。
Pact工具非常的轻量化，易使用，学习成本低，带来的效果显著。

Pact 介绍

Pact 开发术语

Consumer：微服务接口的调用者
Provider：微服务接口的提供者
契约：是由consumer端和provider端共同定义的接口规范，包括接口访问的路径，输入和输出数据。在具体的实施中，是由consumer端生成的一个json文件，并存放在pact broker上
Pact Broker:保存契约文件的服务器

Pact 开发流程

一.**制定契约**
制定契约就是双方定义接口的过程，完成接口文档的编写。
二.**接口双方的命名**

这里的命名在后续写测试用例的时候需要使用
三.**代码实现**

四.**构建过程**
Maven构建的过程会跑测试用例，所以可以自动完成契约文件的生成，上传broker，契约文件的验证等一系列过程
这里要先构建consumer，用来确保先生成契约文件，以免provider的验证的时候取不到。
provider构建时，会启动真实的服务来进行验证。
完成各自构建，联调在出包的时候就已经完成，意味着构建后出的包就基本是一个可发布的状态。