上面的情景是不是似曾相识呢？现今的业务系统已经很少是孤立存在的了，尤其对于一个大公司而言，各个部门之间的配合非常密切，我们或多或少都需要使用兄弟团队或是其他公司提供的接口服务，当然，我们也会给其他兄弟部门提供接口。这样的话，就对我们的联调和测试造成了很大的麻烦。假如各个兄弟部门的步伐完全一致，那么问题就会少很多，但愿望是美好的，现实是残酷的，要做到步伐一致基本是不可能的。所以，对于这种情况，我们的解决方案通常是搭建一个临时的mock server来模拟那些兄弟部门未开发完成的接口，以达到单方面联调测试的效果，我们下面会介绍一些mock小工具。一般来说，搭建这种临时的mock server比较简单，但是往往也意味着功能简单，有时候可能我们得需要为不同的接口进行重复开发以实现特定功能。这样的话问题就来了，随写随仍不是我们互联网人一贯的作风，我们需要将这种基础服务传承下去，要服务于众多的其他互联网人，我们称之为share。那么能不能构建一个通用的mock server呢？自己动手丰衣足食，萌生了自己开发一套mock系统，就有了现在的雏形——xMock，且听我慢慢道来关于mock的二三事。

mock这个单词解释起来，本意就是模拟或者效仿。我们可以把mock理解为一个替身，在软件开发领域，通常就是指模拟对象。

二、为什么需要Mock？Mock是为了解决不同的单元之间由于耦合而难于开发、测试的问题。所以，Mock既能出现在单元测试中，也会出现在集成测试、系统测试过程中。  

如上图所示，A接口依赖于B、C、D三个接口，如果这三个接口没有都准备好的话，我们必须对它们进行模拟才能继续A接口的开发调试。

有了Mock，前后端人员只需要定义好接口文档就可以开始并行工作，互不影响，只在最后的联调阶段往来密切；后端与后端之间如果有接口耦合，也同样能被Mock解决；测试过程中如果遇到依赖接口没有准备好，同样可以借助Mock；不会出现一个团队等待另一个团队的情况。这样的话，开发自测阶段就可以及早开展，从而发现缺陷的时机也提前了，有利于整个产品质量以及进度的保证。

单元测试是TDD实现的基石，而TDD经常会碰到协同模块尚未开发完成的情况，但是有了mock，这些一切都不是问题。当接口定义好后，测试人员就可以创建一个Mock，把接口添加到自动化测试环境，提前创建测试。

比如说，你需要调用一个“墙”外的资源来方便自己调试，就可以自己Mock一个。

假如我们需要调用一个post请求，为了获得某个响应，来看当前系统是否能正确处理返回的“响应”，但是这个post请求会造成数据库中数据的污染，那么就可以充分利用Mock，构造一个虚拟的post请求，我们给他指定返回就好了。

假如我们需要创建一个演示程序，并且做了简单的UI，那么在完全没有开发后端服务的情况下，也可以进行演示。说到演示了，假如你已经做好了一个系统，并且需要给客户进行演示，但是里面有些真实数据并不想让用户看到，那么同样，你可以用Mock接口把这些敏感信息接口全部替换。

假如有一个接口，有100个不同类型的返回，我们需要测试它在不同返回下，系统是否能够正常响应，但是有些返回在正常情况下基本不会发生，难道你要千方百计地给系统做各种手脚让他返回以便测试吗？比如，我们需要测试在当接口发生500错误的时候，app是否崩溃，别告诉我你一定要给服务端代码做些手脚让他返回500 。。。而使用mock，这一切就都好办了，想要什么返回就模拟什么返回，妈妈再也不用担心我的测试覆盖度了！

 四、有哪些mock小工具既然Mock好处这么多，还是赶紧看看有哪些Mock方法吧。下面我介绍下我接触过的一些Mock小方法。1. Mock Server-Moco这是一个jar包，只要执行该jar包，指定配置文件，就可开启一个http服务器提供服务，并且修改配置文件后也无需重启服务，支持动态加载。我使用的是moco-runner-0.10.2-standalone.jar，运行方式如下：```java -jar moco-runner-0.10.2-standalone.jar start -p 8080 -c ***.json```***.json就是我们的mock配置文件，比如：

具体其他使用方法请参照官方文档：https://github.com/dreamhead/moco/blob/master/moco-doc/apis.md

这是一个在线mock网站，操作简单，但url是自动生成的，接口逻辑也无法实现定制化。考虑这样一个场景：前端人员在使用mock接口时，肯定希望接口地址和最终上线的地址完全一样，这样就无需在联调时修改接口地址了，只需配置一个hosts，不然的话，改来改去难免改错。对于这样的场景，这个mock网站就实现不了，更不用说其他更加定制化的需求。

介绍了这么多mock工具，那么哪个最好使呢？我的要求其实不多，一是数据要好管理，别让我管理一堆文件；二是mock接口最好可以设置成和真实接口完全一致，这样就只需要切换hosts就可以切换mock接口和真实接口，不需要修改代码；三是跨平台，mock接口在windows和Linux下都需要可用。至于跨域、动态加载什么的，这是必须条件。我的要求确实不多，但上面介绍的都没法全部满足。

五、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带给我们的便利。