1. GTest简介：
GTest 就是 Google Test, 它是一个免费开源的测试框架, 用于编写测试用 C++语言编写的程序(C 程序也能用, 但是需要用 C++编译器编译)。gtest的官方网站是：http://code.google.com/p/googletest/
2.GTest下载与环境搭建：
GTest 下载地址如下。
http://code.google.com/p/googletest/
由于 Google 被 GFW 墙了,只能通过代理下载,或者从 GitHub 下载也行。
https://github.com/google/googletest
下载并解压之后，就可以看到gtest-1.7.0文件夹了，里面的内容如下图所示
GTEST提供了对于多个不同平台的支持，例如msvc文件夹是用在微软Visual Studio中，xcode文件夹是用于Mac Xcode，codegrear文件夹是用于Borland C++ Builder，在Linux环境中，用的内容就是make文件夹了。为了保持程序的简洁，避免混淆试听，在这一步把所有不需要的文件全部删除，只保留需要的。其实只需要4个文件夹，如下图所示。其余的文件以及文件夹全部删除。
打开make文件夹，会发现里面只有一个Makefile文件。查看Makefile文件内容，得知这是系统给出的编译samples文件夹中的第一个sample的命令。但是打开sample文件夹，又看到里面一大堆源文件。因此，可以打开samples文件夹，开始删文件，删到只剩下如图所示的三个文件为止。
此时如果到make文件夹下，通过命令行执行 $ make && ./sample1_unittest 命令，可以看到测试的执行结果。不过如果打开Makefile查看一下，就会发现这个makefile只适用于编译sample1，如果我再增加一个被测 的源文件，又要重新写makefile，太麻烦了。于是，在这一步，我们改写一下Makefile。现在只剩下4个文件夹（include，make，samples，src），既然make里面的唯一一个文件也要被改写，那也没必要留 这个文件夹了。要做的第一件事情就是，把make文件夹，连同里面的Makefile文件全部删，然后，进入samples文件夹，自己创建一个文件，名为 Makefile，如图所示
然后，打开Makefile文件，写入以下内容，如图所示。这个新的Makefile是由刚才被我们删除的 Makefile改写而来的，里面涉及到一些makefile的语法和函数，注意下图中改写的Makefile第32行，我们编译的是后缀名为cpp的文件，而原来给的例子却以cc结尾。因此，你还要做一件事情，就是把 sample1.cc的文件名改为sample1.cpp，把sample1_unittest.cc的文件名改为 sample1_unittest.cpp，就大功告成了。
现在文件夹有三个（include，src，samples），被测的程序放在sample文件夹中。这个文件夹的名字看着也比较不方便，可以把它改为mycode，然后GTEST根目录的文件夹名称gtest-1.7.0也可以改为mygtest之类，用以满足我们的需求。如图所示：
现在，进入命令行进行编译执行操作： $ make && ./run_test，就可以看到结果了，如图所示：
假设我们现在有一个待测函数sqrt.cpp以及它的头文件sqrt.h，他们的内容如下：
(sqrt.cpp)
(sqrt.h)
(sqrt_unittest.cpp)
这个被测文件的作用是计算任意一个正整数的平方根，算法复杂度在log(n)级别。将以上三个文件放在mycode文件夹中，然后 make && ./run_test进行编译运行，就可以看到结果了：
总结：环境搭建完成之后，每次测试一个文件xxx.cpp以及它的xxx.h文件，就把这俩放入mycode文件夹，然后编写 xxx_unittest.cpp测试文件，也放进去。然后到这个目录下用命令行 make && ./run_test就可以了。要测试时，我们只需要三个文件放入mycode，然后命令行进入这个目录 make && ./run_test 即可完成测试。xxx_unittest.cpp这个文件名并不是固定，取成别的也无所谓，只是这样更容易辨 认哪一个文件是在测哪个函数而已。
3.Mock and Stub
Mock通常是指，在测试一个对象A时，我们构造一些假的对象来模拟与A之间的交互，而这些Mock对象的行为是我们事先设定且符合预期。通过这些Mock对象来测试A在正常逻辑，异常逻辑或压力情况下工作是否正常。
引入Mock最大的优势在于：Mock的行为固定，它确保当你访问该Mock的某个方法时总是能够获得一个没有任何逻辑的直接就返回的预期结果。
Mock Object的使用通常会带来以下一些好处：
隔绝其他模块出错引起本模块的测试错误。
隔绝其他模块的开发状态，只要定义好接口，不用管他们开发有没有完成。
一些速度较慢的操作，可以用Mock Object代替，快速返回。
在测试中，Mock 和Stub都是将被测代码和依赖代码之间的依赖被极大的隔离开来。那么这两者之间的区别是什么呢？
在理解其区别之前，需要明白一点，他们都是为了同一个目标而出现的，代替依赖部分，让原先的“集成测试”简化为“单元测试” mock：在程序代码中向被测试代码注入“依赖部分”，通过编写Mock代码的方式模拟出函数调用返回的结果。（注意：mock是注入，不是替换）
stub：自己写代码代替“依赖部分”。它本身就是“依赖部分”的一个简化实现。(stub是 简单的替换)
实际上，在能够使用mock的时候，就不应该选择使用stub。但是有时候是必须使用stub的，例如在对遗留代码进行测试时，该部分代码不支持“注入”，那么只能将“替代”这个过程外移，使用stub完成此任务了。
| class DataGetter { public: ... bool Run(); ... private: ... Client* m_ptr_client; ... }; ..... ..... bool DataGetter::Run() { ... std::string data; bool ret = m_ptr_client->GetData(data); ... } .... .... |
比如要对run这个函数进行单元测试，它内部调用了ptr_client->GetData(data)的方法，它是通过tcp协议从服务端取数据到data里，测试run这个函数，必然要构造data。
如果不“打桩”，要测试的话，我们就需要再从服务端去构造数据，而且还可能收到其他因素的影响。
原理：利用c++ virtual的特性，改变m_ptr_client指针所指向的对象，重写一个“打桩”测试类。
当然，前提是GetData的定义本身是virtual的。
假设Client的定义如下
class Client { ...... public: virtual bool GetData(std::string& data); ...... };
我们只需要重写Getdata的方法，并且当参数data被传进来时，我们可以返回特定的值。
这一套方法，google已经提供了很好的一套框架：gmock
下面介绍一下它的用法
#include"client.h"//被mock的类的头文件
#include <gmock gmock.h="">// gmock 的头文件
class MockClient :public Client { public: MockClient():Client() {} MOCK_METHOD1(GetData, bool(std::string&)); }</gmock>
这里使用了一个宏MOCK_METHOD1
原形是MOCK_METHOD#1(#2, #3(#4) )
#1表示被mock的函数参数个数，#2表示被mock的函数名称，#3表示被mock的函数返回值，#4表示被mock的函数参数列表
使用mock：
首先，要先改变m_ptr_client指向的对象，对于private的变量（可以使用#define private public 把所有的private变成public去使用），然后测试的时候，直接将 m_ptr_client = new MockClient()即可，不过要记得释放它之前new的资源。
4.GTest用法
|
断言
Google Test支持两类断言 ASSERT和EXPECT:
ASSERT_*系列
当检查失败时，退出当前函数。
EXPECT_*系列
当检查失败时，继续向下执行。
主要用于检查布尔，数值型，字符串，返回成功或失败，异常，浮点，类型。
布尔值检查
| Fatal assertion | Nonfatal assertion | Verifies |
| ASSERT_TRUE(condition); | EXPECT_TRUE(condition); | Condition is true |
| ASSERT_FALSE(condition); | EXPECT_FALSE(condition); | Condition is false |
数值型数据检查
| Fatal assertion | Nonfatal assertion | Verifies |
| ASSERT_EQ(expected, actual) | EXPECT_EQ(expected, actual); | Expected ==actual |
| ASSERT_NE(val1, val2); | EXPECT_NE(val1, val2); | Val1 != val2 |
| ASSERT_LT(val1,val2); | EXPECT_LT(val1,val2); | val1<val2 |
| ASSERT_LE(val1,val2); | EXPECT_LE(val1,val2); | val1<=val2 |
| ASSERT_GT(val1,val2); | EXPECT_GT(val1,val2); | val1>val2 |
| ASSERT_GE(val1,val2); | EXPECT_GE(val1,val2); | val1>=val2 |
字符串检查
| Fatal assertion | Nonfatal assertion | Verifies |
| ASSERT_STREQ(expected_str,actual_str); | EXPECT_STREQ(expected_str,actual_str); | the two C strings have the same content |
| ASSERT_STRNE(str1,str2); | EXPECT_STRNE(str1,str2); | the two C strings have different content |
| ASSERT_STRCASEEQ(expected_str,actual_str); | EXPECT_STRCASEEQ(expected_str,actual_str); | the two C strings have the same content, ignoring case |
| ASSERT_STRCASENE(str1,str2); | EXPECT_STRCASENE(str1,str2); | the two C strings have different content, ignoring case |
- Predicate Assertions
在使用EXPECT_TRUE或ASSERT_TRUE时，有时希望能够输出更加详细的信息，比如检查一个函数的返回值TRUE还是FALSE时，希望能够输出传入的参数是什么，以便失败后好跟踪。因此提供了如下谓词断言：
| Fatal assertion | Nonfatal assertion | Verifies |
| ASSERT_PRED1(pred1, val1); | EXPECT_PRED1(pred1, val1); | pred1(val1)returns true |
| ASSERT_PRED2(pred2, val1, val2); | EXPECT_PRED2(pred2, val1, val2); | pred2(val1, val2)returns true |
| ... | ... | ... |
例：
| bool MutuallyPrime(int m, int n) |
ASSERT_PRED后面的数字表示pred函数有几个参数，目前支持的参数数量为<=5。
- 参数化
在设计测试案例时，经常需要考虑给被测函数传入不同的值的情况。我们之前的做法通常是写一个通用方法，然后编写在测试案例调用它。即使使用了通用方法，这样的工作也是有很多重复性的，程序员都懒，都希望能够少写代码，多复用代码。Google的程序员也一样，他们考虑到了这个问题，并且提供了一个灵活的参数化测试的方案。
例：如果要测一个函数用来判断一个数字是否是质数，我们可能需要测一组数据:
| TEST(IsPrimeTest,HandleTrueReturn) EXPECT_TRUE(IsPrime(17)); |
假如测试的数据有成百上千的时候，那么我们要是写成百上千行代码，这是非常恐怖的，而参数化功能就很好的解决了这个问题，通过使用Gtest的参数化功能，上面的例子变成了：
| classIsPrimeParamTest:public::testing::TestWithParam<int> TEST_P(IsPrimeParamTest,HandleTrueReturn) INSTANTIATE_TEST_CASE_P(TrueReturn,IsPrimeParamTest,testing::Values(3,5,11,23,17)); |
在INSTANTIATE_TEST_CASE_P中第一个参数是测试案例的前缀，可以任意取；
第二个参数是测试案例的名称，需要和之前定义的参数化的类的名称相同，如：IsPrimeParamTest
第三个参数是可以理解为参数生成器，上面的例子使用test::Values表示使用括号内的参数。
Google Test提供了一系列的参数生成的函数:
| Range(begin,end[,step]) | 范围在begin~end之间，步长为step，不包括end |
| Values(v1,v2,…,vN) | V1,v2到vN的值 |
| ValuesIn(Container) ValuesIn(begin,end) | 从一个C类型的数组或是STL容器，或是迭代器中取值 |
| Bool（） | 取false和true两个值 |
- 事件机制
Gtest提供的多种事件机制,事件机制主要是为了了在执行案例之前或之后做一些操作。gtest的事件一共有3种：
全局的，所有案例执行前后。
TestSuite级别的，在某一批案例中第一个案例前，最后一个案例执行后。
TestCase级别的，每个TestCase前后。
Gtest提供的使用方法：
实现全局事件：写一个类，继承testing::Environment类，实现里面的SetUp和TearDown方法。
1. SetUp()方法在所有案例执行前执行
2. TearDown()方法在所有案例执行后执行
TestSuite事件：我们需要写一个类，继承testing::Test，然后实现两个静态方法
1. SetUpTestCase() 方法在第一个TestCase之前执行
2. TearDownTestCase() 方法在最后一个TestCase之后执行
TestCase事件:TestCase事件是挂在每个案例执行前后的，实现方式和上面的几乎一样，不过需要实现的是SetUp方法和TearDown方法：
1. SetUp()方法在每个TestCase之前执行
2. TearDown()方法在每个TestCase之后执行
- 死亡测试
“死亡测试”名字比较恐怖，这里的“死亡”指的的是程序的崩溃。通常在测试过程中，我们需要考虑各种各样的输入，有的输入可能直接导致程序崩溃，这时我们就需要检查程序是否按照预期的方式挂掉，这也就是所谓的“死亡测试”。gtest的死亡测试能做到在一个安全的环境下执行崩溃的测试案例，同时又对崩溃结果进行验证。Gtest提供了一种安全的测试环境，它可以在不影响其他案例执行的情况下，对崩溃案例的结果进行检查。
| ASSERT_DEATH(statement,regex) | EXPECT_DETH(statement,regex) | Statement crashes with the given error |
| ASSERT_EXIT(statement,predicate,regex) | EXPECT_EXIT(statement,predicate,regex) | Statement exits with the given error and its exit code matches predicate |
例子：
| Void Foo() |
- 结果输出
Gtest有两种结果输出方式，一种是直接通过控制台输出结果，另一种方式是通过xml输出结果。
结果输出控制参数：
| 命令行参数 | 说明 |
| --gtest_color=(yes|no|auto) | 输出命令行时是否使用一些五颜六色的颜色。默认是auto。 |
| --gtest_print_time | 输出命令行时是否打印每个测试案例的执行时间。默认是不打印的。 |
| --gtest_output=xml[:DIRECTORY_PATH\|:FILE_PATH] | 将测试结果输出到一个xml中。 1.--gtest_output=xml: 不指定输出路径时，默认为案例当前路径。 2.--gtest_output=xml:d:\ 指定输出到某个目录 3.--gtest_output=xml:d:\foo.xml 指定输出到d:\foo.xml 如果不是指定了特定的文件路径，gtest每次输出的报告不会覆盖，而会以数字后缀的方式创建。 |
5.方法总结：
1.将被测试的Code放在Dummy.cc文件中，
2.将需要做成的桩函数放在Stub.cc文件中
3.测试Case的SourceCode放在Dummy_unittest.cc文件中
4.编译SourceCode
通过终端进行gtest文件夹下的make目录，输入如下的命令
make coverage=yes
5.执行测试测序
编译通过后，会在make目录下生成可执行程序Dummy_unittest
在终端中输入./Dummy_unittest 运行可执行程序
