为什么要抛弃Pact?如何快速实现契约测试(CDC)
发布于 1 个月前 作者 wardennn 512 次浏览 来自 分享

契约测试

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

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

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

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

我做了一张图方便大家理解CDC的概念: 1.png

上图经历了三个步骤:

  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 请求地址前缀。

2.jpg

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

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

3.jpg

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

4.jpg

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

5.jpg

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

6.jpg

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

7.jpg

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

8.jpg

创建测试用例,实现后端的契约测试:

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

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

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

9.png

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

回到顶部