前后端分离：使用 mest 做契约测试跟踪 API 接口变更

还在担心后端 API 变更对前端的影响？快来使用 mest

在实施前后端分离架构的过程中，最让人苦恼的莫过于：API 发生了变化。API 发生变化的原因那可是相当的丰富：业务变化、字段名出错、第三方接口不匹配等等，但是这些都不重要——一个字段从 string 变成了 number，对于前端的影响并不大。

重要的是，后台 API 发生了一些变化，而前端却不知道或者没有人对此作出相应——比如说，某一天你下班了，后台的同事告诉了你，这个 API 变了。结果，第二天这事被忘记了，因此就轻而易举地就创造了一堆 bug。

契约与契约测试

过去，前后端约定好的 API 可能以文档的形式定义，当发生 API 变更的时候，可能以邮件、聊天工具等等不同的形式来通知 API 的消费方。但是，这种方式容易出现问题，比如说：不能通知到团队的所有人、或者相关的消息埋没在消息流中。为此，人们发明了一种以 JSON 作为契约的方式来作为契约好的 API 接口。

契约，是以双方当事人互相对立合致的意思表示所构成的，其中包括要约及承诺两个基本的意思表示。

即，对于前端和后台来说，这个契约就是最后以 JSON 形式展现的 API。它可以用于前端开发时使用的接口，也是后端最后要提供的线上 API 格式：

1. {

2.  "id": 9,

3.  "title": "搭建指南",

4.  "make": {

5.  "id": 8,

6.  "category": 9,

7.  "featured_image": "uploads/make/.thumbnails/guide-map.jpg/guide-map-600x360.jpg"

8.  },

9.  "slug": "搭建指南"

10. }

有了契约，前端不会被前端 Block，可以在后台接口还没开发好的情况下，继续开发工作——只需要在后期做一些集成工作即可。一般来说，对于这样一个契约（接口），它会包含大部分的 API 可能响应的情况，如 200 返回的是正常情况，404 返回 Not Found，401 返回权限异常。这个时候，我们只需要有一个 Mock Server 就可以了，在这个 Mock Server 里，只要能处理 参数、授权等等的内容即可。

然而，契约只是一种承诺，它并不能保证接口提供方能完成遵循这个契约开发。对于接口的提供来说，需要一个有效