消费者驱动的微服务契约测试套件：Spring Cloud Contract

在微服务架构下，你的服务可能由不同的团队提供和维护，在这种情况下，接口的开发和维护可能会带来一些问题，比如服务端调整架构或接口调整而对消费者不透明，导致接口调用失败。

为解决这些问题，Ian Robinson提出了一个以服务消费者定义契约为驱动的开发模式：“Consumer-Driver Contracts(CDC)”，就是：消费者驱动契约。

通常我们开发中主要由服务提供方约定接口，虽然提供方架构调整或改变接口之前通常会通知消费者，但可能还存在上述风险，如果上线出现问题就GG了，而CDC则是以消费者提出接口契约，交由服务提供方实现，并以测试用例对契约进行产生约束，所以服务提供方在满足测试用例的情况下可以自行更改接口或架构实现而不影响消费者。

消费者驱动的契约测试（Consumer-Driven Contracts，简称CDC），是指从消费者业务实现的角度出发，驱动出契约，再基于契约，对提供者验证的一种测试方式。

如果你目前使用SpringCloud作为微服务基础环境，那么集成SpringCloud Contracts也是比较好的选择。

原本你要测试的话必须启动相应的服务。像下面这样：

使用了Spring Cloud Contract之后，你就不需要启动这么多的服务了。像下面这样：

也许你发现了，出现了一个新的生物，叫STUB。这是个什么东西呢？稍后会详细说，这里你先就认为它可以模拟出provider，然后消费者直接调用就可以模拟服务调用了。

是不是不错。

好，接下来我们透过代码来详细的讲解下这个套件吧。

我们接下来模拟一个流程。现在有两个团队，分别负责不同的服务。

这里就假设有provider团队和consumer团队。那么当provider团队的服务还没有开发好，或者provider的团队的服务没有在启动的时候，我们可不可以进行开发呢？

答案是可以的。

契约（Contract）

这里引入一个重要的概念，就是契约，Contract。这是什么呢？很简单，就是provider和consumer事先要约定好一个接口的规范，之后双方提供服务接口和消费服务接口都要按照这个契约来。

先来看看代码的基本结构：

分别有三个模块：common、consumer、provider。

接下来一一介绍：

Common模块

然后分别有两个类，一个是分页Page实体，另外一个是Customer实体类。

1、Customer：

2、Page：

待会我们会在provider和consumer中都用到。

Provider程序

先来看看pom依赖：**