使用场景

前端客户端团队和后端服务端团队往往节奏是不一致的。前端很多情况下需要等待后台的api开发完成后才能进行开发联调和测试,这种前后端不对称就造成了前后端团队节奏不一致,从而造成整个项目/产品交付/发布延期。

有一种解决方案的思路是前后端先约定好后端提供的api接口的细节,前端人员自行先模拟出这些后端的实现,当然这些实现是假的,不过前端可以去调用这些假的实现,而且能拿到返回,这样一来前端就不需要等待后端开发完成才开始工作了。

但是这样还是会有问题,前端实现的假的api没办法迅速反映出后端的变化。简单来说就是后端可能在约定好的api接口上进行了些许修改,而没有知会前端人员,这样前端的假的api实现并没有相应更新,在正式联调时就会出现问题。

像这种假的api实现,不管是前端实现的还是后端去实现的,我们可以称之为mock server。

  • mock表示这个api返回的数据是假的,仅作为测试用的
  • server表示需要启动服务,说到底这是一个服务程序

契约测试

由于前后端往往有一些信息不对称,导致约定的api可能在前后端都会发生变化,所以保证前后端的一致性就成了一个挑战。

这时候有人提出了契约测试,大致思想是前后端共用一份契约,约定了api的细节,前后端的任何变化都需要先修改契约,然后通过契约去通知前后端团队,统一更新实现。这也是契约精神的表现。

如果为契约测试设置一种测试工具的话,我会规划下面一些特性

  • 契约的描述工具:也就是契约长什么样子,用什么工具去定义才能让前后端团队秒懂

  • 通过契约自动生成mock server实现,这样前端团队就可以拿来即用了,如果契约修改了,那么前端团队也很容易感知到

  • 通过契约自动生成接口测试用例,这样通过持续运行这些接口测试用例,后端团队就可以第一时间发现契约的修改