前后端分离-mock接口的功与过

场景

 1）接口尚未开发完成

前后端项目中，后端接口开发完成之前，接口联调；

依赖的上游项目的接口尚未开发完成，需要接口联调测试；

2)    接口返回不满足目前需求

目前的接口虽然已实现，但个别字段/返回不满足目前的测试要求（比如，一个字段有3中状态，但接口只能返回2种）

接口mock的几个阶段

阶段一：直接修改对应的DB数据，使其对应的接口返回满足要求

适用场景：

仅仅使用接口已存在，但不满足要求的情况下；

优点：比较快速；不需要代码做修改；

缺点：不适用大批接口、或接口尚未存在的情况

阶段二：使用代理工具如fiddler，charles等工具将接口请求重定向

使用场景：

接口存在，但不满足要求；

接口不存在，但接口文档已定义好；

优点：针对已存在的接口，修改个别字段， 方便快捷；可重复使用；前端若ajax,则不需要前端做任何修改

缺点：每次测试要打开代理工具(如果代理工具含有上次不需要的重定向，有可能被误用)；后端无法调用；

阶段三: mock框架/平台

适用场景：大批量接口需要mock时

优点：mock接口可反复使用；前端若ajax,则借助代理工具不需要前端做任何修改(后端调用mock接口需要修改代码做适配)

缺点：mock的接口需要维护；上线前要修改配置文件(将mock接口改为实际接口，千万不能遗忘了！！！)

ps: mock的开发可参看：http://blog.csdn.net/huazhongkejidaxuezpp/article/details/50508455

mock的“功”

有了mock之后：

1） 前后端分离；

2） 上下游系统开发分离；

3） 测试时，异常返回的测试；

总之，开发效率和测试的深度都会大大提高了。

mock的“过”

这里说mock的过，主要是让开发和测试不要过分的依赖/相信mock接口。mock接口后，即便已经做了非常充分的测试，当把mock接口换成实际接口后，测试/开发也必须把之前的测试重新做一遍，否则便可能出现“你以为对的接口，实际却错了”。

使用mock时，切记的几点：

1） 当把mock接口换成实际接口后，测试/开发也必须把之前的测试重新做一遍。

ps: 当你使用mock接口来提高效率，请注意：你的工作量其实是比 直接只用实际接口 多了 一倍的。如果测试时，偷懒，替换成实际接口后，只是简单测试，那么 当实际接口和mock预期接口有差异时，故障便和你相遇了。

建议： mock接口只能主流程联调/ 异常返回测试，不要过分依赖mock接口进行测试。

2） 测试完毕，上线前，请一定确保 为了mock而做的相关代码/配置文件的修改，已经完全恢复了。

建议：上线checklist中条条列出，并上线前review