契约测试：解决微服务测试的问题

为什么是契约测试

契约测试（ContractTest）第一次看到我是在 Martin Fowler 的文章里。（原文在这里感兴趣的可以去看看https://martinfowler.com/bliki/ContractTest.html）

在他的这篇文章了，首先说了一下 TestDouble 的劣势，其中 TestDouble（对这个定义感兴趣可以见https://martinfowler.com/bliki/TestDouble.html）

其实我们也很少提及。为了解释契约测试，我们在本文吧 TestDouble 替换成 MOCK，这也行并不正确，但是可以快速让我们理解。

MOCK 服务相信很多人都知道主要是用了帮助解决外部依赖而存在的。在两个团队分别负责 Service1 和 Service2 的开发，其中 Service1 调用 Service2。在测试过程中很容易由于 Service1 和 Service2 之间网络速度、服务不稳定等问题导致的无法测试 Service1，那么这个时候我们很多人第一个想到的是 Service2 用 MOCK 服务替代掉。这也确实是一个行之有效的方法。

但是现在开发周期、迭代周期和迭代频率都在变短、变快，如果 Service1 在开发或者测试的使用应用了 Service2 的 MOCK 服务，同时 Service2 也被自己的 Own 团队进行了升级迭代，但是 Service1 调用的 MOCK 服务没有升级，这就导致了集成测试的时候才能发现两边不一致的问题，这将大大影响项目或者迭代周期的进度。

在微服务大行其道的今天，各种服务接口（provider）又被各种服务调用（comsumer），生产者消费者模式就促生了契约测试（更应该叫消费者驱动的契约测试，Cunsumer-Driven Contracts，简称 CDC），CDC 就是从消费者的角度定义测试，通过给 API 提供方提供契约的形式，来完成功能的实现。当今比较主流的 CDC 测试框架有 PACT（https://github.com/pact-foundation/pact-specification）

cdc 核心原则 (转自：https://www.cnblogs.com/jinjiangongzuoshi/p/7815243.html:）

cdc 是以消费者提出接口契约，交由服务提供方实现，并以测试用例对契约进行产生约束，所以服务提供方在满足测试用例的情况下可以自行更改接口或架构实现而不影响消费者。

cdc 是一种针对外部服务的接口进行的测试，它能够验证服务是否满足消费方期待的契约。 它的本质是从利益相关者的目标和动机出发，最大限度地满足需求方的业务价值实现。

Pact 的契约测试流程

如上图，使用 Pact 完成契约测试后，首先我们还是按照原来的测试用例对 Consumer 进行测试，在需要 Consumer 和 Provider 发生交互的时候，Provider 被替换成和 Pact 交互。在测试过程中，Pact 会记录下全部的 Provider 的调用请求（保存在一个 Json 文件中），这就是消费者的契约。如果在执行 Provider 的测试的时候，就不需要从新完成 Provider 的测试用例，只需将 Pact 记录下来的消费者契约作为测试的输入，完成和 Provider 的交互，来验证 Provider 是否满足了消费者契约。

这也说明了契约测试既不是单元测试也不是集成测试，是出于单元测试和集成测试之间的一层测试行为。

Pact 官方给出的几个场景：

（转自： https://insights.thoughtworks.cn/about-contract-test/）

适用场景：

团队能把控开发过程中的 Consumer 和 Provider 端
适合 Consumer 驱动开发的场景
对于每个独立的 Consumer 端，Provider 端都能管理好需求。

不适用的场景：

公共 API 或者是 OAuth 授权服务
Provider 端和 Consumer 端没有良好的沟通渠道
针对性能的测试
Provider 端的功能性测试（Pact 只测试内容和请求格式）
对于不同输入有相同的输出，并未达到验证的目的
当前测试输入需要依赖之前测试返回的结果

参考

https://www.cnblogs.com/jinjiangongzuoshi/p/7815243.html
http://aleung.github.io/blog/2017/06/21/pact/
https://insights.thoughtworks.cn/about-contract-test/