为什么要抛弃 Pact？如何快速实现契约测试（CDC）

[vocalman]

契约测试

为前后端对接的过程中会出现信息不对称，以及工作进度不一致的情况，因此希望通过事先约定好 API 返回数据的文档，根据文档来开发后端代码，以及生产可以被前端调用的虚拟的 API，帮助前后端能够同时开展工作并且保持前后端代码的正确性，加快后期的系统集成测试甚至是取消系统集成测试。

我们将以上的做法称之为契约测试。契约测试最开始的概念由 Martin Fowler 提出，它又被称之为：消费者驱动的契约测试（ Consumer Driven Contracts ），简称 CDC。这里的契约是指软件系统中各个服务间交互的数据标准格式，更多的指消费端（ client ）和提供端（ server ）之间交互的 API 的格式。

契约测试带来的变化主要是：

1. 将前后端测试解耦，前后端可以分别在对方还没有完成工作的时候就开展测试；
2. 将测试过程前移，加速或者取代集成测试；
3. 保证数据的一致性，让后端服务返回的数据就是前端想要得到的。

我做了一张图方便大家理解 CDC 的概念：

上图经历了三个步骤：

1. 消费者（广义的前端）根据业务需要编写好契约文件，契约文件里面编写了需要返回的数据；
2. 消费者（广义的前端）向契约文件（实际上是一个 API 服务）发起请求，得到预期的结果，验证前端业务逻辑是否正确；
3. 契约文件（实际上是一个 API 服务）向提供者（广义的后端）发起请求，得到后端真实的返回结果并且与契约文件中的数据规则进行校验，判断后端返回的数据是否满足契约的要求。如果无法通过校验，说明提供者的服务发生了改变，或者是没有按照契约所规定的来进行开发。

如果通过了上面的三步，我们可以认为前后端对于契约的理解和实现是一致的，等到真正集成之后也不会出现问题。

Pact 契约测试框架

之前业内较为常见的做法是通过 Pact （一个契约测试框架）进行契约测试：通过前端开发人员编写代码进行测试并生成 Pact 契约文件，后端通过 Pact Brocker 等服务管理契约以及调用等。

但是 Pact 也存在一些缺点：

1. 需要引入 Pact 的相关文件以及正确搭建服务，用起来需要一定的时间成本
2. 生成的返回数据不够灵活，无法编写代码生成复杂的随机数据；
3. 无法判断请求参数来返回不同的结果；
4. 需要开发人员额外编写代码，增加了工作量；
5. 存在代码入侵的情况，并且目前支持的语言较少；
6. 模糊了开发与测试人员之间的界限，管理不当容易导致重复劳动；

由于有以上的不足之处，Pact 在实际应用的效果往往并不理解。因此我们提出了通过 Mock API 以及测试用例实现更快速、更有效地契约测试。

通过 EOLINKER API Studio 实现契约测试

EOLINKER API Studio （https://www.eolinker.com） 提供了 UI 实现的 Mock API，配合 API Studio 的测试用例与自动化测试，可以帮助研发团队更快速、更有效地实现契约测试。

什么是 Mock API ？

通过 Mock API，您可以事先编写好 API 的数据生成规则，由 API Studio 动态生成 API 的返回数据。开发人员通过访问 Mock API 的 URL 来获得所需要的数据，完成对接工作。

在 API Studio 中，同一个项目中的 Mock API 的地址前缀是相同的（如 mock.eolinker.com/uasyd1/…），因此可以在代码中将 Mock API 的地址前缀作为全局变量，项目上线时仅需替换变量的值即可改变整个项目的 API 请求地址前缀。

创建 Mock API，实现前端的契约测试

在 EOLINKER API Studio 中，创建 Mock API 之前需要先创建 API 文档（或者导入 Postman、Swagger 等数据），API 文档可以作为前后端对接的依据。这里我创建了一个简单的用户登录 API 文档：

创建好 API 文档之后，点击 Mock API 标签进入 Mock API 的管理页面，在这里可以快速创建多个 Mock API，并且根据不同的请求参数返回相应的数据：

创建一个 Mock API 期望，我们希望当传递 user_name=123 和 user_psw=112233 时，Mock Server 返回登录成功的数据，这里返回的数据类型选择 Json，填写好 Json 的格式以及内容即可：

点击预览按钮可以看到是我们希望得到的返回数据，然后确定保存即可：

通过这种方式可以创建多个 Mock API，并且通过请求红框处的 Mock API URL 得到返回结果：

API Studio 中也提供了强大的 API 测试的功能，我们直接在平台上对刚才的登录成功的 Mock API 发起请求，可以看到当我们传递正确的参数时，可以得到预期的返回结果，至此契约测试的前端契约就已经完成了：

创建测试用例，实现后端的契约测试：

传统的契约测试其实并不能够保证测试的覆盖率，因为前端开发人员提供的契约文件很可能无法覆盖所有的请求情况，导致出现漏测的情况。

因此 API Studio 建议将后端的契约测试交给测试人员负责，这样可以提供更完善的测试用例，并且可以结合各类 CI 工具实现自动化测试。

由于 API Studio 基于 API 文档来实现契约测试、API 用例测试、API 自动化测试等功能，因此可以将前端、后端、测试人员解耦，工作的流程可以进一步改进为下图所示，前后端、测试人员可以同时开展工作，并且测试用例可以导入到自动化测试中成为长期的定时测试任务。

由于测试用例与自动化测试所包含的内容较多，如有需要可以前往 EOLINKER API Studio 官方网站（https://www.eolinker.com）或者是查阅 API Studio 帮助文档，在此不再赘述。