C++单元测试工具，现在市面上有很多并且不少都是免费开源的，这次要介绍的是gmock，来自大名鼎鼎的Google，gmock是包含了gtest的一个单元测试框架，在gtest基础上增加了许多便于开发人员进行mock打桩的接口等，可以理解为gtest负责进行测试，gmock负责测试前的打桩，gmock比起其他的cppunit等测试工具来说，最大的优点就是可以有简单的内置宏来定义一个类的mock类进行打桩，这为C++类单元测试带来了极大的便利。
【编译gmock】
解压缩gmock-1.7.0.zip，将解压后的文件上传至linux服务器。
cd进入gmock-1.7.0/make目录，输入make直接编译，完成后在make目录下执行./gmock_test，打印如下内容，则说明编译成功：
之后再次执行make gmock.a命令生成gmock静态库（内含gtest），会在make目录下变成生成gmock.a，将gmock.a文件更名为libgmock.a后拷贝到自己环境的库目录中之后就可以在自己的单元测试工程的make文件中通过添加-lgmock参数来连接gmock了。
【使用gmock】
介绍一个简单的例子：
现有Foo.h和Foo.cpp两个文件，文件内容如下：
现在要对Foo函数进行单元测试。
在Foo.cpp相同目录下新建一个Foo_test.cpp文件，文件内容如下：
这里有两个宏TEST和EXPECT_EQ， TEST这个宏，它有两个参数，这两个参数的解释为：[TestSuiteName，TestCaseName]，测试套间名，测试用例名。
为本次测试新建一个makefile，内容如下：
执行make test编译，编译成功后，./test执行测试。
【Gmock中的断言】
在上一节的示例中，可以看到EXPECT_EQ来检查函数返回结果已确定用例是否测试通过，这个EXPECT_EQ就是一种断言宏，在gmock/gtest中，断言的宏可以理解为分为两类，一类是ASSERT系列，一类是EXPECT系列。
一个直观的解释就是：
▪ ASSERT_* 系列的断言，当检查点失败时，退出当前函数（注意：并非退出当前案例）。
▪ EXPECT_* 系列的断言，当检查点失败时，继续往下执行。
以上两种断言类型下根据比较的数据类型又进一步：
布尔数据检查
数值型数据检查
字符串类型检查
异常检查
浮点型检查
【Gmock打桩并测试】
在C++项目中，会有大量接口类方法的调用，下面就介绍一个简单的对抽象接口类进行mock打桩测试的例子，在这个例子中我们有一个interface.h里面定义了如下接口类：
新建一个inteface_mock.cpp文件
注：在实际使用时，应当将基类中的所有纯虚函数进行打桩，否则会编译报错。
▲几个宏的说明：MOCK_METHOD#1(#2， #3(#4) )
#1表示你要mock的方法共有几个参数
#2是你要mock的方法名称
#3表示这个方法的返回值类型
#4是这个方法具体的参数
以上就已经完成了对接口类的mock，但打桩的工作还没有全部完成，还需要设置某个成员函数执行时能按我们的期望来返回值，我们继续往下看。
选择一个要进行单元测试的文件s_ls_dosomething.cpp，里面只有一个函数：
再新建一个s_ls_dosomething_ut.cpp作为s_ls_dosomething.cpp这个文件中函数单元测试文件，内容如下：
之前在完成interface_mock.cpp的时候说打桩还没有全部完成，剩下的工作就在这个TEST中了，就是通过ON_CALL/ EXPECT_CALL来设定桩函数的返回值，这2个宏的具体说明如下：
ON_CALL(#1， #2(#3)).WillByDefault(Return(#4));
#1表示mock对象
#2表示想定义的那个方法名称。
#3表示定义方法的参数，只有当传入的参数=#3的值时，才会生效，也可用_，表示匹配任何参数输入都生效
#4表示调用要返回值。
除了ON_CALL以外，还有EXPECT_CALL(#1， #2(#3))，参数含义同ON_CALL，还可以有额外的功能，比如:
EXPECT_CALL(#1， #2(#3)).Times(5).WillOnce(Return(100))
.WillOnce(Return(150))
.WillRepeatedly(Return(200));
表示第一次返回100，第二次调用返回150，后面全部返回200，以此类推。
ON_CALL和EXCEPT_CALL相当于设置桩函数的属性设置，因此应当在桩函数调用前进行设置。除了TEST宏函数定义和main函数之外，在例子中可以看到我还定义了SubServiceCall，由于这个函数会向Fbase发送服务调用请求，但我们用MockF2Pack打的包其实是空无一物，调用服务显然会使测试过程不可控，因此我们把这个函数也进行打桩。
到这里，打桩和单元测试用例编写工作算是完成了，编译并生成一个单元测试的可执行文件，然后执行，就完成了一个文件的单元测试工作。