产品经理：前端开发进度如何？
前端小A同学：我的页面依赖服务端接口，但小B同学开发的接口有各种问题，所以。。 产品经理：抓狂ing 产品经理：Hi，小B同学，你负责的接口开发进度如何了，什么时候能提测？
服务端小B同学：我的接口依赖于兄弟部门的xx接口，他们那边开发进度太慢，导致我没法从他们那获取数据，联调不了，暂时无法提测。。 产品经理：吐血ing 产品经理：Hi，小C同学，这个系统测试进度怎么样了，今天能上线吗？
测试小C同学：逗我玩呢，这个系统依赖的第三方接口都没准备好，有的根本没有测试环境，今天测完，臣妾做不到啊！ 产品经理：#@￥%￥￥！@# 上面的情景是不是似曾相识呢？
没错，我们经常会遇到各种各样接口依赖的问题困扰着我们，于是，在很久以前，就有了―mock‖这种东西。
一、什么是mock？
至于mock这个单词解释起来，本意就是模拟或者效仿。我们可以把mock理解为一个替身，在软件开发领域，通常就是指模拟对象或者fake。
二、为什么需要Mock？
Mock是为了解决不同的单元之间由于耦合而难于开发、测试的问题。所以，Mock既能出现在单元测试中，也会出现在集成测试、系统测试过程中。
如上图所示，A接口依赖于B、C、D三个接口，如果这三个接口没有都准备好的话，我们必须对它们进行模拟才能继续A接口的开发调试。
三、Mock的好处是什么？
1.团队可以并行工作
有了Mock，前后端人员只需要定义好接口文档就可以开始并行工作，互不影响，只在最后的联调阶段往来密切；后端与后端之间如果有接口耦合，也同样能被Mock解决；测试过程中如果遇到依赖接口没有准备好，同样可以借助Mock；不会出现一个团队等待另一个团队的情况。这样的话，开发自测阶段就可以及早开展，从而发现缺陷的时机也提前了，有利于整个产品质量以及进度的保证。 2.开启TDD模式，即测试驱动开发
单元测试是TDD实现的基石，而TDD经常会碰到协同模块尚未开发完成的情况，但是有了mock，这些一切都不是问题。当接口定义好后，测试人员就可以创建一个Mock，把接口添加到自动化测试环境，提前创建测试。 3.可以模拟那些无法访问的资源
比如说，你需要调用一个―墙‖外的资源来方便自己调试，就可以自己Mock一个。 4.隔离系统
假如我们需要调用一个post请求，为了获得某个响应，来看当前系统是否能正确处理返回的―响应‖，但是这个post请求会造成数据库中数据的污染，那么就可以充分利用Mock，构造一个虚拟的post请求，我们给他指定返回就好了。 5.测试覆盖度
假如有一个接口，有100个不同类型的返回，我们需要测试它在不同返回下，系统是否能够正常响应，但是有些返回在正常情况下基本不会发生，难道你要千方百计地给系统做各种手脚让他返回以便测试吗？比如，我们需要测试在当接口发生500错误的时候，app是否崩溃，别告诉我你一定要给服务端代码做些手脚让他返回500 。。。而使用mock，这一切就都好办了，想要什么返回就模拟什么返回，妈妈再也不用担心我的测试了覆盖度了！ 6.
7.可以用来演示
假如我们需要创建一个演示程序，并且做了简单的UI，那么在完全没有开发后端服务的情况下，也可以进行演示。说到演示了，假如你已经做好了一个系统，并且需要给客户进行演示，但是里面有些真实数据并不想让用户看到，那么同样，你可以用Mock接口把这些敏感信息接口全部替换。
四、有哪些mock小工具
既然Mock好处这么多，还是赶紧看看有哪些Mock方法吧。下面我介绍下我接触过的一些Mock小方法。
1.wiremock wiremock是一个jar包，我下载的是wiremock-1.57-standalone.jar。比较轻便，大多数情况下直接使用jar包就够了，无需额外编程工作。在控制台或者终端运行如下命令启动wiremock：
1.java -jar wiremock-1.30-standalone.jar
将会启动一个http服务器来处理将要mock的请求，默认监听8080端口。 运行上面的命令后，我们会发现在jar包所在目录生成了两个目录，分别为files（放置一些上传或者下载的文件）和mappings（放置请求和返回的映射）。 在mappings目录下，创建请求处理文件mytest-mapping.json，写入以下内容：
2.
3.4.5.6.7.8.9.10.11.12.13.14.15.{
\"request\":{ \"method\":\"GET\", \"url\":\"/api/mytest\" },
\"response\":{ \"status\":200,
\"bodyFileName\":\"mytest.json\", \"headers\":{
\"Content-Type\":\"application/json\", \"Cache-Control\":\"max-age=86400\" } } } 每个字段意思基本明了，这里我们指定的请求url是http://127.0.0.1:8080/api/mytest，response中的bodyFileName字段指定了响应内容放在mytest.json中，这个文件放在files目录下，内容如下：
16.17.18.{
\"errno\":0 }
以上我们就配置好了请求以及所需要的响应，然后在浏览器打开http://127.0.0.1:8080/api/mytest，就会返回配置好的响应。
当然，也可以不用把响应单独放在__files中，直接在mytest-mapping.json中指定也可以，比如：
19.20.21.22.23.24.25.26.27.28.29.30.31.32.{
\"request\":{ \"method\":\"GET\", \"url\":\"/api/mytest\" },
\"response\":{ \"status\":200,
\"body\":\'{\"name\":\"a\"}\', \"headers\":{
\"Content-Type\":\"application/json\", \"Cache-Control\":\"max-age=86400\" } } }
当然wiremock还有一些其他功能，比如返回网络异常，设置服务延时等等，若需深入了解，请自行查找其他资料。 不过wiremock有几个明显的缺点，主要如下：
o o 请求与响应都必须以文件的形式存储，不好管理
每次文件更新后，必须得手动重启wiremock。当然你也可以通过一个daemon程序来监控文件的变化，自动重启wiremock，但这也是后话了。
o 无法跨域。若要支持跨域则需要修改wiremock本身代码。
Mock Server-Moco 这也是一个jar包，和上面的wiremock类似，但是他比wiremock更先进，支持的mock方式更多，而且我们修改配置文件后也无需重启服务，可以动态加载。我使用的是moco-runner-0.10.2-standalone.jar，运行方式如下：
0.java -jar moco-runner-0.10.2-standalone.jar start -p 8080-c ***.json
***.json就是我们的mock配置文件，比如：
1.2.3.4.5.6.7.8.9.10.11.12.[ {
\"description\":\"api 1\", \"request\":{ \"method\":\"get\", \"uri\":\"/foo\" },
\"response\":{
\"json\":{\"foo\":\"bar\"} } } ]
以上就可以实现当我们访问127.0.0.0:8080/foo时，返回一个json为{―foo‖:‖bar‖}。
具体其他使用方法请参照官方文档：https://github.com/dreamhead/moco/blob/master/moco-doc/apis.md fiddler fiddler大家都很熟了，可谓是居家旅行之必备，在windows环境可以随便自定义返回内容，但一个很大的缺点是，它不跨平台，而我们平时很多场景下，是需要在Linux下进行mock的。 www.daodoc.com 这是一个在线mock的网站，操作简单，相比wiremock，它支持跨域，但url是自动生成的，无法定制。考虑这样一个场景：前端人员在使用mock接口时，肯定希望接口地址和最终上线的地址完全一样，这样就无需在联调时修改接口地址了，只需配置一个host，改来改去难免改错。对于这样的场景，这个网站就实现不了了。而且数据都是在人家网站上存储的，对于以后接口的各种形式的定制化也实现不了。 还有一些其他mock工具，大多都是通过编写js代码或者python、java等代码来达到mock目的，此处就不再介绍了。
介绍了这么多mock工具，那么哪个最好使呢？我的要求其实不多，一是数据要好管理，别让我管理一堆文件；二是mock接口最好可以设置成和真实接口完全一致，这样就只需要切换hosts就可以切换mock接口和真实接口，不需要修改代码中的url；三是跨平台，mock接口在windows和Linux下需要同时满足。至于跨域、动态加载什么的，这是必须要满足的。我的要求确实不多，但上面介绍的都没法全部满足。
五、xMock系统诞生始末
现今的业务系统已经很少是孤立存在的了，尤其对于一个大公司而言，各个部门之间的配合非常密切，我们或多或少都需要使用兄弟团队或是其他公司提供的接口服务，当然，我们也会给其他兄弟部门提供接口。这样的话，就对我们的联调和测试造成了很大的麻烦。假如各个兄弟部门的步伐完全一致，那么问题就会少很多，但愿望是美好的，现实是残酷的，要做到步伐一致基本是不可能的。所以，对于这种情况，我们的解决方案通常是搭建一个临时的server来模拟那些兄弟部门未开发完成的接口，以达到单方面联调测试的效果，我们上面介绍的这些众多小工具就是这样的，我们称之为mock server的雏形。一般来说，搭建这种临时的mock server比较简单，但是往往也意味着功能简单，有时候可能我们得需要为不同的接口进行mock server的重复开发以实现特定功能。这样的话问题就来了，随写随仍不是我们互联网人一贯的作风，我们需要将这种基础服务传承下去，要服务于众多的其他互联网人，我们称之为share。那么能不能构建一个通用的mock server呢？自己动手丰衣足食，萌生了自己开发一套mock系统，就有了现在的雏形——xMock。 xMock是BS架构，web页面录入接口信息后，可以在任何平台下调用mock接口，满足了跨平台；接口信息保存在数据库中，解决了文件方式不好管理的问题；web页面录入接口信息，任何人都可以，不需要代码知识，门槛低；通过nginx访问配置好的mock接口，后台统一处理请求信息，进行url匹配，解决了mock接口和真实接口完全一致的问题。
xMock系统使用非常简单，只要三步：填写项目信息，在对应项目下填写接口信息，配置hosts即可访问。页面如下：
xMock系统的核心——mockserver，采用nginx作为前端代理，将接收到的所有请求全部转发到后台mockserver，mockserver接收到请求后，对url进行预处理，根据url以及请求方式，在数据库中查找对应的响应并返回，流程如下图：
好，xMock系统搭建起来了，正好有个需求，我们需要调用360移动开放平台的一个获取特定账号下app信息的接口，但是这个接口在测试环境下无法得到想要的信息，好了，我们按照真实接口的返回格式，将我们想要的返回以及其他信息录入xMock，然后在Linux配置hosts，将接口地址设置成提供mock服务的服务器ip，web产品页面调用接口，欧耶，顺利返回了设置好的内容！
这就是mock带给我们的便利。 xMock目前能解决哪些问题呢？
– 依赖的第三方系统接口还没开发完毕，影响自己的开发进度；
– FE依赖RD提供的接口进行开发，而接口还没有完成或频繁重启； – QA需要验证接口某种特定返回值或返回状态，而又不好通过功能模拟，比如支付； – 性能测试，需要同步第三方系统或特定接口数据，需要从新搭建系统或申请权限、造大量数据；
– 与通过修改项目代码写死或者代码mock这种mock方式而言，xMock做到了无需编写任何代码、对项目没有任何副影响；
– Fiddler只能在Windows平台，大量mock切换需要频繁操作。
xMock将来要解决哪些问题呢？
其实，我们目前只是有了mock最基本的功能，但对于接口而言，它的行为可能会有很多可以模拟的地方，比如：
– 我们有时候会测试当接口超时时，app端是否会正确提示，还是一直等待资源，也就是说，我们需要模拟超时情况；
– 服务端和移动端进行通讯时，为了防止劫持，通常会将关键接口进行参数或者body加解密，也就是说，我们需要模拟加解密；
– 我们有时候会需要根据传参的值来动态决定返回的内容，也就是说，我们需要模拟接口逻辑；
– 我们有时候还得模拟https或者其他协议头甚至自有协议； – 需要支持不同端口的url； – 能够响应文件、流媒体等；
– 能够支持mock接口响应内容缓存到redis； – 等等等等……
要做的还有很多，欢迎提供宝贵意见！同时，也欢迎加入我们的产品与开发团队！ 附系统访问地址：http://jiekouceshi.com
