1 现有的单元测试框架
单元测试是保证程序正确性的一种有效的测试手段，对于不同的开发语言，通常都能找到相应的单元框架。
借助于这些单测框架的帮助，能够使得我们编写单元测试用例的过程变得便捷而优雅。框架帮我们提供了case的管理，执行，断言集，运行参数，全局事件工作，所有的这些使得我们只需关注：于对于特定的输入，被测对象的返回是否正常。
那么，这些xUnit系列的单元测试框架是如何做到这些的了？分析这些框架，发现所有的单元测试框架都是基于以下的一种体系结构设计的。
如上图所示，单测框架中通常包括TestRunner, Test, TestResult, TestCase, TestSuite, TestFixture六个组件。
TestRuner：负责驱动单元测试用例的执行，汇报测试执行的结果，从而简化测试
TestFixture：以测试套件的形式提供setUp()和tearDown()方法，保证两个test case之间的执行是相互独立，互不影响的。
TestResult：这个组件用于收集每个test case的执行结果
Test：作为TestSuite和TestCase的父类暴露run()方法为TestRunner调用
TestCase：暴露给用户的一个类，用户通过继承TestCase，编写自己的测试用例逻辑
TestSuite：提供suite功能管理testCase
正因为相似的体系结构，所以大多数单元测试框架都提供了类似的功能和使用方法。那么在单测中引入单元测试框架会带来什么好处，在现有单元测试框架下还会存在什么样不能解决的问题呢？
2 单元测试框架的优点与一些问题
在单元测试中引入单测框架使得编写单测用例时，不需要再关注于如何驱动case的执行，如何收集结果，如何管理case集，只需要关注于如何写好单个测试用例即可；同时，在一些测试框架中通过提供丰富的断言集，公用方法，以及运行参数使得编写单个testcase的过程得到了最大的简化。
那这其中会存在什么样的疑问了？
我在单元测试框架中写一个TestCase，与我单独写一个cpp文件在main()方法里写测试代码有什么本质却别吗？用了单元测试框架，并没有解决我在对复杂系统做单测时遇到的问题。
没错，对于单个case这两者从本质上说是没有区别的。单元测试框架本身并没有告诉你如何去写TestCase，在这一点上他是没有提供任何帮助的。所以对于一些复杂的场景，只用单元测试框架是有点多少显得无能为力的。
使用单元测试框架往往适用于以下场景的测试：单个函数，一个class，或者几个功能相关class的测试，对于纯函数测试，接口级别的测试尤其适用，如房贷计算器公式的测试。
但是，对于一些复杂场景：
被测对象依赖复杂，甚至无法简单new出这个对象
对于一些failure场景的测试
被测对象中涉及多线程合作
被测对象通过消息与外界交互的场景
…
单纯依赖单测框架是无法实现单元测试的，而从某种意义上来说，这些场景反而是测试中的重点。
以分布式系统的测试为例，class 与 function级别的单元测试对整个系统的帮助不大，当然，这种单元测试对单个程序的质量有帮助；分布式系统测试的要点是测试进程间的交互：一个进程收到客户请求，该如何处理，然后转发给其他进程；收到响应之后，又修改并应答客户；同时分布式系统测试中通常更关注一些异常路径的测试，这些场景才是测试中的重点，也是难点所在。
Mock方法的引入通常能帮助我们解决以上场景中遇到的难题。
3 Mock的引入带来了什么
在*上这样描述Mock：In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior. of a human in vehicle impacts.
Mock通常是指，在测试一个对象A时，我们构造一些假的对象来模拟与A之间的交互，而这些Mock对象的行为是我们事先设定且符合预期。通过这些Mock对象来测试A在正常逻辑，异常逻辑或压力情况下工作是否正常。
引入Mock最大的优势在于：Mock的行为固定，它确保当你访问该Mock的某个方法时总是能够获得一个没有任何逻辑的直接就返回的预期结果。
Mock Object的使用通常会带来以下一些好处：
隔绝其他模块出错引起本模块的测试错误。
隔绝其他模块的开发状态，只要定义好接口，不用管他们开发有没有完成。
一些速度较慢的操作，可以用Mock Object代替，快速返回。
对于分布式系统的测试，使用Mock Object会有另外两项很重要的收益：
通过Mock Object可以将一些分布式测试转化为本地的测试
将Mock用于压力测试，可以解决测试集群无法模拟线上集群大规模下的压力
4 Mock的应用场景
在使用Mock的过程中，发现Mock是有一些通用性的，对于一些应用场景，是非常适合使用Mock的：
真实对象具有不可确定的行为(产生不可预测的结果，如股票的行情)
真实对象很难被创建(比如具体的web容器)
真实对象的某些行为很难触发(比如网络错误)
真实情况令程序的运行速度很慢
真实对象有用户界面
测试需要询问真实对象它是如何被调用的(比如测试可能需要验证某个回调函数是否被调用了)
真实对象实际上并不存在(当需要和其他开发小组，或者新的硬件系统打交道的时候，这是一个普遍的问题)
当然，也有一些不得不Mock的场景：
一些比较难构造的Object：这类Object通常有很多依赖，在单元测试中构造出这样类通常花费的成本太大。
执行操作的时间较长Object：有一些Object的操作费时，而被测对象依赖于这一个操作的执行结果，例如大文件写操作，数据的更新等等，出于测试的需求，通常将这类操作进行Mock。
异常逻辑：一些异常的逻辑往往在正常测试中是很难触发的，通过Mock可以人为的控制触发异常逻辑。
在一些压力测试的场景下，也不得不使用Mock，例如在分布式系统测试中，通常需要测试一些单点（如namenode，jobtracker）在压力场景下的工作是否正常。而通常测试集群在正常逻辑下无法提供足够的压力（主要原因是受限于机器数量），这时候就需要应用Mock去满足。
在这些场景下，我们应该如何去做Mock的工作了，一些现有的Mock工具可以帮助我们进行Mock工作。