前后端预联调mock数据解决方案

[chiyan-lin]

前端er 在业务开发完成之后，有些高效的小伙伴也许会在联调时间开始之前就完成。

这个时候要是把测试数据写在静态页面中, 在发布的是忘记删除就会产生极大的冗余代码, 对维护造成困难, 并且写在页面中的数据也没有联动效果, 仿真效果差, 接入 api 时才发现有很多问题。

所以在后端接口还未发布的时候，希望能有一种模拟数据的工具，来产出对应的数据堆，这个方式最好是能贴近真实联调的行为，减少 dev 过程和真实联调过程的修改成本。

方案1

后端在拟定完成接口的时候，会输出一份输入接口和输出接口。

后端能否提供一个 dev 的域名，这个域名专门用于 mock 数据，根据接口和输出接口产生模拟数据，开发的时候就可以用这个 dev 域名来获取数据，在正式联调的时候就已经把相对完整的功能交互做完。

方案2

一切工作在前端做，后端输出的文档里面把数据复制出来，放到本地的 mock.json 文件中，在 mock 的模式下，将原本的网络请求指向这个实际的文件获取具体数据。

这两个方案，从简便性而言，明显是 方案1 来的很实在，当时要是让后端来负责这个维护似乎有点繁重，需要后端同学维护一个域名，还要考虑数据mock过程的变动性，对他们来说，他们不关心联调前的数据问题，mock 只是前端同学用来提升自己效率的一个工具。

至于 方法2，在每次数据结构变动的时候，自己维护的数据json也需要自己手改，明显不是一个合理的解决方案。

基于 ts interface & mockjs 自动生成测试数据

背景

后端给到前端的接口协议从原本的文档变成了 pb 协议，大致的格式如下

service LuckyBag {
    rpc IsDividing (IsDividingReq) returns (IsDividingRsp);
}

message IsDividingReq {
    string fid = 1;
}
message DivideRsp {
    common.Result result = 1;
}

这是后端和前端根据产品文档和交互稿约定好的数据格式。

详细方案

有了这份 pb 协议，可以做的事情就很多的，增加前端的开发效率和开发体验，要做到下面几点

• ts支持，根据pb协议自动生成支持 tree shaking 的 api 函数 ts 文件
• mock 数据支持，根据字段的类型生成对应的类型的随机类型的值
• 页面发出的请求可以被拦截，而且可以在network面板看到实际的数据

上面三个是这个工具的基础目标

pb协议生成接口

这个一个单独的模块，项目上对请求进行了一次封装，希望在导出api函数的时候可以生成 LuckyBag.ts 文件，文件内容如下

export function IsDividing(req: IsDividingReq): DivideRsp {
    return sendData(req)
}
...

每一份依赖的协议都生成这样的文件，前端同学在开发的过程就省去了很多复制粘贴的工作量，避免复制过程的手抖操作。

加上ts的加持，在项目实际调用的时候，参数也可以实时被校验，避免传参和取参错误。

mock数据

mock 数据也是依赖了这一份pb协议，可以看到请求和响应前面都有字段的标示，在处理的过程中，就可以把这块数据取出来
利用 mockjs 的携带的自动生成的随机数据的能力，来自动化产mock数据。

模拟真实联调场景

mockjs 的实现是拦截 XMLHttpRequest ，然后自己重写了一套 XMLHttpRequest，页面请求发出的时候，直接把数据返回，这个时候在 network 面板是看不到返回的数据，这点体验不是很好。

mockjs 拦截了原生的 XMLHttpRequest ，这对于生产环境还是有一定风险的。所以想了一个更加贴近实际的方案，就是自己产出一个具体的服务，修改 webpack 的 server proxy ，让接口请求指向这个服务，服务通过具体的匹配工作，返回具体的mock数据。

[chiyan-lin]

写完了后两篇文章来补充下汇总

方案对比

在查找对比资料的时候，找到了一些其他的解决方案

mockm，Yapi 这两款方案都是在页面上配置接口，然后写具体返回数据。

其实就是将自动化生成的操作转成手动创建的过程，提供一个web操作界面反而显的相对繁琐。本来开发时间就被压榨，mock数据本就是锦上添花的功能，需要人工去添加这些mock数据在接口很多的时候，相对比较麻烦了。