为何要抛弃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 帮助文档，在此再也不赘述。