-
团队可以并行工作
有了Mock，前后端人员只需要定义好接口文档就可以开始并行工作，互不影响，只在最后的联调阶段往来密切；后端与后端之间如果有接口耦合，也同样能被Mock解决；测试过程中如果遇到依赖接口没有准备好，同样可以借助Mock；不会出现一个团队等待另一个团队的情况。这样的话，开发自测阶段就可以及早开展，从而发现缺陷的时机也提前了，有利于整个产品质量以及进度的保证。
2. 开启TDD模式，即测试驱动开发
单元测试是TDD实现的基石，而TDD经常会碰到协同模块尚未开发完成的情况，但是有了mock，这些一切都不是问题。当接口定义好后，测试人员就可以创建一个Mock，把接口添加到自动化测试环境，提前创建测试。
3. 可以模拟那些无法访问的资源
比如说，你需要调用一个“墙”外的资源来方便自己调试，就可以自己Mock一个。
4. 隔离系统
假如我们需要调用一个post请求，为了获得某个响应，来看当前系统是否能正确处理返回的“响应”，但是这个post请求会造成数据库中数据的污染，那么就可以充分利用Mock，构造一个虚拟的post请求，我们给他指定返回就好了。
5. 可以用来演示
假如我们需要创建一个演示程序，并且做了简单的UI，那么在完全没有开发后端服务的情况下，也可以进行演示。说到演示了，假如你已经做好了一个系统，并且需要给客户进行演示，但是里面有些真实数据并不想让用户看到，那么同样，你可以用Mock接口把这些敏感信息接口全部替换。
6. 测试覆盖度
假如有一个接口，有100个不同类型的返回，我们需要测试它在不同返回下，系统是否能够正常响应，但是有些返回在正常情况下基本不会发生，难道你要千方百计地给系统做各种手脚让他返回以便测试吗？比如，我们需要测试在当接口发生500错误的时候，app是否崩溃，别告诉我你一定要给服务端代码做些手脚让他返回500 。。。而使用mock，这一切就都好办了，想要什么返回就模拟什么返回。
7.一些比较难构造的Object：这类Object通常有很多依赖，在单元测试中构造出这样类通常花费的成本太大。 -
根据需求选择恰当的mock点
对于Mock这里存在两个误区，1.是Mock的对象越多越好；2.Mock会引入巨大的工作量，通常得不偿失。这都是源于不恰当的Mock点的选取。
这里说的如何选择恰当的mock点，是说对于一个被测对象，我们应当在外围选择恰当的mock对象，以及需要mock的接口。因为对于任意一个对象，任意一段代码逻辑我们都是有办法进行Mock的，而Mock点选择直接决定了我们Mock的工作量以及测试效果。从另外一种意义上来说，不恰当Mock选择反而会对我们的测试产生误导，从而在后期的集成和系统测试中引入更多的问题。
在mock点的选择过程中，以下的一些点会是一些不错的选择
- 网络交互：如果两个被测模块之间是通过网络进行交互的，那么对于网络交互进行Mock通常是比较合适的，如RPC
- 外部资源：比如文件系统、数据源，如果被测对象对此类外部资源依赖性非常强，而其行为的不可预测性很可能导致测试的随机失败，此类的外部资源也适合进行Mock。
- UI：因为UI很多时候都是用户行为触发事件，系统本身只是对这些触发事件进行相应，对这类UI做Mock，往往能够实现很好的收益，很多基于关键字驱动的框架都是基于UI进行Mock的
- 第三方API：当接口属于使用者，通过Mock该接口来确定测试使用者与接口的交互。
- 当然如何做Mock一定是与被系统的特性精密关联的，一些强制性的约束和规范是不合适的。这里介绍几个做的比较好的mock的例子。