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

前言

在前几天的博客中，我转载了一篇文章，其中介绍了契约测试和pact是怎么实施的，的确很有帮助。但我经过研究，其实是pact本身也是有缺陷的，结合我近期在使用的服务型工具和我的实际情况，觉得实现契约测试其实有更有效率的解决方案，本文就通过我的视角看看我是如何快速实现契约测试的。

契约测试

为前后端对接的过程中会出现信息不对称，以及工作进度不一致的情况，因此希望通过事先约定好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=和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 帮助文档，在此不再赘述。