gtest 单元测试“全自动化”小工具

单元测试重要，单元测试需要一个完美的框架解决方案，gtest正好是这个解决方案；不过用的时候

发现还是有些不怎么爽的地方，最不爽的地方：

1，gtest如果要使用test case中的静态函数或者静态成员，必须要在cpp文件中定义 static 成员

不知道是不是我用的不对，还是本来就这样蛋疼；如果有cpp文件，那我就在cpp中手动加这个定义算了；但

如果我要测试的代码就是一个h头文件呢？我要加到哪里去？

2，独立的单元测试cpp入口，重复的main函数，如下

就是说，如果我的server需要对一个类进行单元测试，我就要手动建一个unit_testor.cpp的文件，

里面写上这么几行代码，然后还要把这个代码放到svn中去！！我是非常讨厌这类可以说是无用的代码的，

纯粹充数而已！！

#include <gtest/gtest.h>
#include "./msg_broadcast_module/msg_file_cache.h"
int main(int32_t argc, char **argv)
{
    testing::InitGoogleTest(&argc, (char**)argv);
    return RUN_ALL_TESTS();
}

3，严重的头文件包含问题

测试代码肯定需要包含目标被测代码，也就意味着要在上面这个cpp文件中加入业务头文件，每加

一个不同的单元测试，就需要加一个头文件；本来人就懒得不想写测试代码了，如果还要去手动维护这些

包含被包含关系，没人愿意去写单元测试...

看1，2，3点，基本都是机械无聊的纯手工活，我讨厌手工活，这些活应该可以用机器自动完成...

单元测试的目的是辅助目标代码，所以一般来说，我是非常倾向与把单元测试代码放到目标代码头

文件的下面的，这样有几个好处，1，单元测试代码起到了一个文档的作用，极好的说明了目标代码怎么用！

2，紧密的和目标代码放在一起，模块的概念更强；我是比较反感把测试代码全放一个testor.cpp里面的，

测试代码不应该和目标代码分离；

使用方法：

1，在被测头文件下面写如下代码：

#include <gtest/gtest.h>
using namespace testing;

class MsgFileCacheTest : public testing::Test
{
};
TEST_F(MsgFileCacheTest, TestMsgFile)
{
//测试代码....
}

2，在makefile包含：http://blog.chinaunix.net/uid-26443921-id-3263449.html

中的makefile即可

3，make test//makefile 自动生成 unit test.cpp，自动扫描项目下的所有的头文件，把所有的

单元测试扫描出来，生成static变量，生成 include 包含；然后自动编译完成，生成目标可执行 unit

testor

就这么简单；

关键实现工具就 check_unit_testor.sh 这个shell脚本，其实原理很简单，就是把无聊机械的手活

改成机器做了而已；

代码具体实现中对 gtest 加了20来行代码，比较简单的代码，代码放 github 上了；