初识 Contract Testing

诞生背景

现代的软件开发项目中，基于微服务的开发模式越来越常见，然而，随着项目规模的扩大，服务间的依赖越来越重要，团队间的协调也越来越紧密，当不同的开发团队去开发不同的服务时，服务的变动会影响到众多消费它的用户，为了保证系统的正确性和一致性，这将需要大量的沟通成本和代码修改的时间成本。

为了解决这类团队间的合作问题，Contract Testing应运而生。在实际项目经历中用好契约测试会大大增强开发及测试的效率。

 

什么是 Contract Testing

Contract Testing，中文契约测试，是一种新型的测试方法，用来确保两个通信系统，比如服务端和客户端，或者两个微服务，能够像期望一样地通信、工作。契约测试会捕获两个服务间的交互行为，把它们存放在称为契约的文档中，这个契约文档就是两者交互行为的标准，可以用来检验任何一方都遵守该契约的行为。

契约测试和传统的测试通信协议的方法最大的不同在于，一旦契约文档确立了，两个系统可以单独进行测试，而无需放在一起测试。另外一个特点是，契约测试中的契约，通常是用代码自己生成的，而不是手工编写，这意味着契约能够始终cover最新协议变化。

 

Contract Testing 的价值

传统集成测试的问题

当我们开发了两个需要通信的微服务，或者典型的C/S应用程序，在把他们部署到生成环境前，我们需要确保他们都能和对方以期望的方式工作，当向对方发送特定的请求，我们期望对方返回特定的响应。为此，我们需要写集成测试用例，并在QA环境运行实际的、预部署的应用程序。两个服务间的测试看似还比较简单，但是当整套系统中的微服务过多时，相应的集成测试成本将呈指数级增长。

所以集成测试的优缺点很明显：

✅ 给与足够的信心部署；

❌ 应用间的依赖性

❌ 需要较长时间获得测试结果反馈

❌ 应用过多时容易出错

❌ 需要很多测试环境的维护成本

为何不把测试分开

是否可以考虑把需要测试的应用程序分开，对于每个应用，用一个模拟的 peer 来测试它的行为，这样可以保证每个应用程序的单向工作符合需求。

这样设计的利弊是：

✅ 每个应用程序可以独立运行测试用例，没有依赖

✅ 快速获得测试结果反馈

✅ 稳定

✅ 容易维护

❌ 无法给与我们足够的 confidence 去 release

缺点的原因是，它无法保证那个模拟的 peer 和真实的 peer 有相同的 behavior。

Contract Testing 的作用

契约测试通过一张“契约”，维护两边的测试，保持同步一致，从而解决了该方法的缺点。当测试 consumer 端，每个发往模拟 Provider 的请求都被记录在契约文件里，它期望的 response 也记录在文件里。

接下来，模拟 Consumer 按照契约里的记录，向真实 Provider 重新发送每个请求，然后比较真实 Provider 返回的响应是否和合约里记录的期望的响应一致，如果它们一致的话，就可以确认模拟的程序和真实的程序有相同的 behavior，这也意味着两个真实的应用程序可以和对方成功交互。

现在，我们解决了两端分开测试的缺点，所以可以说：

✅ 每个应用程序可以独立运行测试用例，没有依赖

✅ 快速获得测试结果反馈

✅ 稳定

✅ 容易维护

✅ 有足够的 confidence 去 release

 

共享 Contract

一旦实行了 Contract Testing，我们就需要一些方法来管理或共享测试过程中的契约，这就是Pact Broker这个工具的功能。它能帮助我们：

✅ 在团队间分享契约

✅ 管理不同代码版本和环境使用的契约

✅ 知道什么时候可以安全部署

✅ 集成到我们软件开发过程和工具集中

Pact Broker相当于的一个文件服务器，用来管理不同版本、不同应用间的契约。你可以使用PactFlow官方提供的Pact Broker服务，也可以自己在本地搭建一个Pact Broker服务器。

 

参考

https://docs.pact.io/

---

- 全文完 -