一、概述
测试是软件流程中非常重要，不可或缺的一个环节。一般的测试分为单元测试，集成测试，端到端的手工测试，这也是构成测试金字塔的三个层级。我们今天将要讨论的话题是契约测试，它是处于单元测试和集成测试中间的一个环节。这三个层级分别测试的场景如下：
- 单元测试：测试单个service
- 集成测试：测试由多个services组成的系统
- 端到端测试：测试从用户到各个外部系统的整个场景
契约测试的作用：
- 测试接口和接口之间的正确性
- 验证服务层提供的数据是否是消费端所需要的
- 将本来需要在集成测试中体现的问题前移，更早的发现问题
- 更快速的验证消费端和提供端之间交互的基本正确性
二、为什么要存在契约测试
首先我们将使用以下示例模型来描述微服务测试背后的概念：
图1
在上面的图中，我们可以看到有两个微服务，通过REST彼此进行通信。第一项服务扮演消费者的角色，第二项扮演提供者的角色。
当需要进行集成测试时，可以通过服务虚拟化来模拟正在与之通信的微服务。这里服务提供者被模拟，在部署消费者服务之前，您希望证明其能正常工作。当运行所有测试均为绿色您认为可以部署您的服务了。
图2
但是，如果您针对生产提供商运行服务，而不是模拟版本，则有可能会失败。在这个例子中，提供者已经改变了数据格式。集成测试无法解决这个问题，因为它们正在针对Provider的过时版本运行。
图3
如何填补测试过程中的这个空白？将引入消费者驱动契约测试的概念。消费者驱动契约测试方法是在消费者和提供者之间定义在它们彼此之间转移的数据格式。通常，合同的格式由消费者定义并与相应的提供商共享。之后，执行测试以验证契约是否相符。CDC测试的先决条件之一是可以与提供商服务团队保持良好的最佳密切沟通，分享这些契约和交流测试结果是实施适当的CDC测试的重要部分。
三、PACT测试框架
PACT是一个开源的CDC测试框架。它提供了广泛的语言支持，如Ruby，Java，Scala，.NET，Javascript，Swift/Objective-C。
PACT的工作原理
消费者作为数据的最终使用者非常清楚、明确的知道需要的什么样格式，什么类型的数据，它将负责创建契约文档（包含结构和格式的json文件），服务提供端将根据消费者端创建的契约文档提供对应格式的数据并返回给消费者，通过契约检查判断如果服务端提供的数据和消费者生成的契约不匹配，将抛出异常并提示给服务提供端。
四、Spring Cloud Contract
Spring Cloud Contract是一个基于消费者驱动契约的测试框架。它会基于契约来生成存根服务，消费方不需要等待接口开发完成，就可以通过存根服务完成集成测试。Spring Could Contract中，契约是用一种基于 Groovy 的 DSL 定义的。
谈到契约测试时，我们首先需要定义一个包含期望使用接口的第一个文件。作为标准PACT法则，契约必须由消费者服务来定义，但是在Spring Cloud Contract中，它实际上位于提供者服务代码中。在指南手册中包含了两个大步骤：
服务提供者
- 编写合同规范（Groovy DSL）
- 在Provider端生成自动验收测试
- 生成WireMock JSON存根＆将存根发布到Maven（本地）存储库
服务消费者
- 在消费者端配置Stub Runner
- 执行消费者测试 - Stub Runner嵌入了WireMock
- 检查验证结果
4.1 服务提供者
我们在服务端编写一个简单服务接口，判断数字是奇数还是偶数
4.1.1 MAVEN依赖
对于我们的提供者，我们需要spring-cloud-starter-contract-verifier依赖：
需要将我们的基础测试类的名称配置到spring-cloud-contract-maven-plugin：
4.1.2 基础测试类
需要在加载Spring上下文的测试包中添加一个基类：
4.1.3 测试存根
在/src/test/ resources/contracts/目录中，我们将在groovy文件中添加测试存根。例如
当我们运行构建时，运行 mvn clean install 插件会自动生成一个名为ContractVerifierTest的测试类，它扩展我们的BaseTestClass并将其放在/target/generated-test-sources/contracts/中。
测试方法的名称派生自前缀“ validate_”与我们的Groovy测试存根的名称连接。对于上面的Groovy文件，生成的方法名称将为“validate_shouldReturnEvenWhenRequestParamIsEven”。
我们来看看这个自动生成的测试类：
构建还将在我们的本地Maven存储库中添加存根jar，以便我们的消费者可以使用它。
4.2 服务消费者
我们的CDC消费者将通过HTTP交互生成的存根来维护契约，因此提供者方面的任何更改都将破坏契约。
新建BasicMathController，它将发出HTTP请求以从生成的存根中获取响应：
4.2.1 MAVEN依赖
对于我们的消费者，我们需要添加spring-cloud-contract-wiremock和spring-cloud-contract-stub-runner依赖项。还有本地Maven存储库中的可用存根：
4.2.2 存根运行器
现在是时候配置我们的存根运行器，它将通知我们的消费者如何调用我们本地Maven存储库中的可用存根：
通过@AutoConfigureStubRunner自动注入StubRunner,模拟服务方。
参数ids定位到maven中的stub.jar。
Ids = groupId : artifactId : version（’+’表示最新版本）: 存根 : StubRunner端口
如果你将stub.jar发布到Maven私服中，可以通过repositoryRoot参数指定私服地址来远程调用。在测试通过后会根据契约返回响应内容。
五、总结
文中首先介绍了契约测试的背景以及基于CDC开发服务的大致过程。然后编写契约文件通过Spring Cloud Contract的contract verifier插件生成存根和服务提供方的测试用例，消费方编写测试用例，通过StrubRunner模拟服务方来完成一次消费方调用服务方的测试。
参考文章