7

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

为什么是契约测试

契约测试（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/

本文转载自异步社区

原文链接：https://www.epubit.com/articleDetails?id=Nb44cfb5b-bcd9-4df7-b543-7deff778bad2