乐趣区

为什么要抛弃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 帮助文档,在此不再赘述。

退出移动版