随着微服务应用越来越复杂，如何进行可靠的测试也变得越来越重要。契约测试就是一种流行的微服务测试方法。本文将介绍基于Pact框架的契约测试实现。

什么是契约测试

契约测试是验证服务的Provider是否按照期望的方式与服务的Consumer进行交互，简单的说是Consumer与Provider两者之间的集成。而Contract即合同、契约，就是Provider与Consumer的交互方式。

基于消费者驱动的契约测试分两个阶段：

（1）Consumer生成契约，开发者在Consumer端写测试时Mock掉Provider，运行测试生成契约文件；

（2）Provider验证契约，开发者拿契约文件直接在Provider端运行测试进行验证。

 Pact 基本流程

简要流程：

• 第一步在消费者端Consumer端写一个对接口发送请求的单元测试，在运行这个单元测试的时候，Pact会将服务提供者自动用一个MockService代替，并自动生成契约文件，这个契约文件是Json形式的。

• 第二步在Provider端做契约验证测试，将Provider服务启动起来以后，通过pact插件可以运行一个命令，比如你是用maven，就是mvn pact:verify，它会自动按照契约生成接口请求并验证接口响应是否满足契约中的预期，所以可以看到这个过程中，在消费者端不用启动Provider，在服务提供端不用启动Consumer，却完成了与集成测试类似的验证。

详细流程：

**基于消费者的业务逻辑，驱动出契约 **

其实现步骤如下所示：
　　1、使用Pact的DSL，定义Mock提供者，如localhost:8080
　　2、将Mock地址传给消费者并对Mock的提供者发送请求。
　　3、使用Pact的DSL，定义响应内容(包括Headers、Status以及Body等)。
　　4、在消费者端 使用@PactVerification运行单元测试(Pact集成了JUnit、RSpec等框架)，生成契约文件。
　　5、当运行测试后，Pact框架记录消费者的名称、发送的请求、期望的响应以及元数据，将其保存为当前场景下的契约文件，通常命名为[Consumer]-[Provider].json，例如 orderConsumer-orderProvider.json
　　6、契约文件生成后，我们可以将其保存在文件系统或者Pact-Broker(Pact提供的中间件，用来管理契约文件)中，以便后续提供者使用。

**基于消费者驱动出的契约，对提供者进行验证 **

在提供者端，我们不需要写任何验证的相关代码，Pact已经提供了验证的接口，我们只需要做好如下配置：

1、为提供者指定契约文件的存储源(如文件系统或者Pact-Broker)。
2、启动提供者，运行PactVerify(Pact有Maven、Gradle或者Rake插件，提供pactVerify命令)。
3、当执行pactVerify时，Pact将按照如下步骤，自动完成对提供者的验证：
构建Mock的消费者。
4、根据契约文件记录的请求内容，向提供者发送请求。
5、从提供者获取响应结果。
6、验证提供者的响应结果与Pact契约文件定义的契约中是否一致。

Pact 特性

传统情况下做集成测试需要把服务消费者和服务提供者两个服务都启动起来再进行测试，而Pact做契约测试时将它分成两步来做，每一步里面都不需要同时启动两个服务。

1、测试解耦，就是服务消费与提供者解耦，甚至可以在没有提供者实现的情况下开始消费者的测试。
2、一致性，通过测试保证契约与现实是一致性的。
3、测试前移，可以在开发阶段运行，并作为CI的一部分，甚至在开发本地就可以去做，而且可以看到一条命令就可以完成，便于尽早发现问题，降低解决问题的成本。

4、Pact提供的Pact Broker 可以自动生成一个服务调用关系图，为团队提供了全局的服务依赖关系图。

5、Pact提供Pact Broker这个工具来完成契约文件管理，使用Pact Broker后，契约上传与验证都可以通过命令完成，且契约文件可以制定版本。

6、使用Pact这类框架，能有效帮助团队降低服务间的集成测试成本，尽早验证当提供者接口被修改时，是否破坏了消费者的期望。
7、Pact目前仅支持REST HTTP 通信，但对于RPC的通信机制，暂不支持。