温故而知新：gtest单元测试工具和lcov覆盖率统计工具的结合使用
之所以叫温故而知新，是因为将这两个工具结合起来作为单元测试工具的想法在上一个项目中应用了，好像还没有人将这两种工具结合使用，或者没有写成博客供大家参考，现在重新温习下将想法写下来。
gtest单元测试工具接触过的人都很熟悉了，它是一款google提供的强大的测试框架，测试案例的编写也比较简单，gtest案例的编写可以参考系列博文:http://www.cnblogs.com/coderzh/archive//1426758.html。
lcov代码覆盖率统计工具，是gcov的延伸版本，提供程序实际执行的信息（统计某行代码被执行的次数），其基于HTML的输出通过浏览器以清晰的图表形式呈现覆盖率统计结果。locv相关详细介绍可以参考博文：https://my.oschina.net/alphajay/blog/33725。
二、gtest环境的搭建步骤：
（1）下载源码包搭建：
参考博文：http://www.linuxidc.com/Linux/894.htm。
我是按照这篇博客的步骤下载源码将多余的目录删除最后在gtest_tool目录下只剩下两个核心代码目录：
（2）直接输入命令安装： sudo apt-get install libgtest-dev
三、lcov工具的安装：
（1）下载源码包：http://ltp.sourceforge.net/coverage/lcov.php
（2）解压：tar xvzf lcov-1.11.tar.gz
（3）cd lcov-1.11
（4）如果是交叉编译移植到实机上需要执行这步：
修改文件：lcov-1.11/bin/genifo
vim lcov-1.11/bin/genifo
然后将第65行的：our $gcov_tool = "gcov" 改为自己的交叉编译器的gcov
比如我的交叉编译工具是/usr/local/arm/4.3.2/bin/arm-linux-gcc
那么就改为：our $gcov_tool = "/usr/local/arm/4.3.2/bin/arm-linux-gcov"
可以使用：find / -name *gcov来查找下自己的交叉编译工具在什么目录下
（5）sudo make install
注：除了下载源码包还可以执行下面两条命令安装：
sudo apt-get install lcov
sudo apt-get install ggcov
四、将两者结合使用实例
环境搭建好后可以开心得玩耍了 哈哈
（1）首先了解下我需要测试的代码模型：
说明：这是我自己写的简单的消息传递及监听模型测试代码。messageModelLib目录是消息传递模型的核心代码，
编译出来一个.so库供该目录的其他模块使用。messageModelLib目录内容如下：
（2）重点是gtest_lcov目录，该目录是专门用来进行单元测试的，目录内容如下：
说明：gtest_tool 为gtest源码的删减版，lcov-1.11为lcov源码包编译后的目录，lcov_out为自己建的目录用来存放lcov工具统计出的结果的输出。test_case.c为编写的测试用例，内容如下：
// Copyright 2005, Google Inc.
// All rights reserved.
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions are
* Redistributions of source code must retain the above copyright
// notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
// copyright notice, this list of conditions and the following disclaimer
// in the documentation and/or other materials provided with the
// distribution.
* Neither the name of Google Inc. nor the names of its
// contributors may be used to endorse or promote products derived from
// this software without specific prior written permission.
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
// A sample program demonstrating using Google C++ testing framework.
// Author:
(Zhanyong Wan)
// This sample shows how to write a simple unit test for a function,
// using Google C++ testing framework.
// Writing a unit test using Google C++ testing framework is easy as 1-2-3:
// Step 1. Include necessary header files such that the stuff your
// test logic needs is declared.
// Don't forget gtest.h, which declares the testing framework.
#include &limits.h&
#include "gtest/gtest.h"
#include "myComDef.h"
#include "responser12.h"
#include "listener12.h"
extern "C" {
#include "log_out.h"
// Step 2. Use the TEST macro to define your tests.
// TEST has two parameters: the test case name and the test name.
// After using the macro, you should define your test logic between a
// pair of braces.
You can use a bunch of macros to indicate the
// success or failure of a test.
EXPECT_TRUE and EXPECT_EQ are
// examples of such macros.
For a complete list, see gtest.h.
// &TechnicalDetails&
// In Google Test, tests are grouped into test cases.
This is how we
// keep test code organized.
You should put logically related tests
// into the same test case.
// The test case name and the test name should both be valid C++
// identifiers.
And you should not use underscore (_) in the names.
// Google Test guarantees that each test you define is run exactly
// once, but it makes no guarantee on the order the tests are
// executed.
Therefore, you should write your tests in such a way
// that their results don't depend on their order.
// &/TechnicalDetails&
// Tests Factorial().
// Tests factorial of negative numbers.
static responser1 res1_
static responser2 res2_
static listener1 lis1_
static listener2 lis2_
TEST(apl_registResponserTest, isTrue)
ASSERT_EQ(TRUE, apl_registResponser(RES1, RES_MID, &res1_instance));
ASSERT_EQ(TRUE, apl_registResponser(RES2, RES_HIGH, &res2_instance));
TEST(apl_registListenerTest, isTrue)
ASSERT_EQ(TRUE, apl_registListener(RES1, &res1_instance, &lis1_instance));
ASSERT_EQ(TRUE, apl_registListener(RES2, &res2_instance, &lis2_instance));
TEST(loop_send_test, isRight)
int n = 0;
while(n & 10)
MSG_INFO msgI
char msgData[128];
msgInfo.resType = RES1;
//设置动作对象
msgInfo.msg.eventID = R1_FUN1; //设置应该做什么动作
EXPECT_EQ(TRUE, apl_sendMessage(RES1, R1_FUN1, msgData)); //发送开始消息及动作参数
//apl_unRegistResponser(RES1);
msgInfo.msg.eventID = R1_FUN2;
int a = 10, b = 122;
apl_msgPacker(msgData,sizeof(int), &a,sizeof(int), &b, -1);
EXPECT_EQ(TRUE, apl_sendMessage(RES1, R1_FUN2, msgData));
msgInfo.resType = RES2;
msgInfo.msg.eventID = R2_FUN1;
double c = 4.23, d = 2.32;
apl_msgPacker(msgData,sizeof(double), &c,sizeof(double), &d, -1);
EXPECT_EQ(TRUE, apl_sendMessage(RES2, R2_FUN1, msgData));
msgInfo.msg.eventID = R2_FUN2;
apl_msgPacker(msgData,sizeof(int), &a,sizeof(int), &b, -1);
EXPECT_EQ(TRUE, apl_sendMessage(RES2, R2_FUN2, msgData));
// Step 3. Call RUN_ALL_TESTS() in main().
// We do this by linking in src/gtest_main.cc file, which consists of
// a main() function which calls RUN_ALL_TESTS() for us.
// This runs all the tests you've defined, prints the result, and
// returns 0 if successful, or 1 otherwise.
// Did you notice that we didn't register the tests?
// RUN_ALL_TESTS() macro magically knows about all the tests we
// defined.
Isn't this convenient?
主要测试三个case，消息回应者、对应监听器的注册和消息的传递和监听。
编写好test_case.c以后文件以后，关键的关键就是makefile的编写了，我的makefile是gtest源码包example测试makefile基础上修改的，内容如下：
# A sample Makefile for building Google Test and using it in user
Please tweak it to suit your environment and project.
# may want to move it to your project's root directory.
# SYNOPSIS:
make [all]
- makes everything.
make TARGET - makes the given target.
make clean
- removes all files generated by make.
# Please tweak the following variable definitions as needed by your
# project, except GTEST_HEADERS, which you can use in your own targets
# but shouldn't modify.
# Points to the root of Google Test, relative to where this file is.
# Remember to tweak this if you move this file.
GTEST_DIR = ./gtest_tool
#gtest 源码所在目录
# Where to find user code.
USER_DIR = ..
#测试代码所在目录
# Flags passed to the preprocessor.
# Set Google Test's header directory as a system directory, such that
# the compiler doesn't generate warnings in Google Test headers.
CPPFLAGS += -isystem $(GTEST_DIR)/include
# Flags passed to the C++ compiler.
CXXFLAGS += -g -Wall -Wextra -pthread
CXXFLAGS2 += -g -Wall -Wextra -pthread -fprofile-arcs -ftest-coverage #多了两个编译选项
# All tests produced by this Makefile.
Remember to add new tests you
# created to the list.
TARGET = appMain
# the link library you should change according to your need
LINK_LIB = -L$(USER_DIR)/lib -lSendMsgModel -lpthread -lrt
# All Google Test headers.
Usually you shouldn't change this
# definition.
GTEST_HEADERS = $(GTEST_DIR)/include/gtest/*.h \
$(GTEST_DIR)/include/gtest/internal/*.h
# House-keeping build targets.
all : $(TARGET)
# Builds gtest.a and gtest_main.a.
# Usually you shouldn't tweak such internal variables, indicated by a
# trailing _.
GTEST_SRCS_ = $(GTEST_DIR)/src/*.cc $(GTEST_DIR)/src/*.h $(GTEST_HEADERS)
# For simplicity and to avoid depending on Google Test's
# implementation details, the dependencies specified below are
# conservative and not optimized.
This is fine as Google Test
# compiles fast and for ordinary users its source rarely changes.
gtest-all.o : $(GTEST_SRCS_)
g++ $(CPPFLAGS) -I$(GTEST_DIR) -c \
$(GTEST_DIR)/src/gtest-all.cc
gtest_main.o : $(GTEST_SRCS_)
g++ $(CPPFLAGS) -I$(GTEST_DIR) -c \
$(GTEST_DIR)/src/gtest_main.cc
gtest.a : gtest-all.o
$(AR) $(ARFLAGS) $@ $^
gtest_main.a : gtest-all.o gtest_main.o
$(AR) $(ARFLAGS) $@ $^
# Builds a sample test.
A test should link with either gtest.a or
# gtest_main.a, depending on whether it defines its own main()
# function.
XX_SOURCES = $(wildcard $(USER_DIR)/myListeners/*.cpp $(USER_DIR)/myResponsers/*.cpp)
CC_SOURCES = $(wildcard $(USER_DIR)/logout/*.c)
XX_OBJECTS = $(patsubst %.cpp,%.o,$(XX_SOURCES))
CC_OBJECTS = $(patsubst %.c,%.o,$(CC_SOURCES))
INCLUDE_DIRS = -I$(USER_DIR)/include -I$(USER_DIR)/myListeners -I$(USER_DIR)/myResponsers -I$(USER_DIR)/logout
TEST_CASE_O = ./test_case.o #gtest 测试案例
$(TEST_CASE_O) : %.o : %.c
$(XX) -c $(CPPFLAGS) $& -o $@ $(INCLUDE_DIRS)
$(CC_OBJECTS) : %.o : %.c
$(CC) -c $(CXXFLAGS2) $& -o $@ $(INCLUDE_DIRS)
#需要用lcov查看哪个文件的代码覆盖率，编译的时候就加上-fprofile-arcs -ftest-coverage编译选项
$(XX_OBJECTS) : %.o : %.cpp
$(XX) -c $(CXXFLAGS2) $& -o $@ $(INCLUDE_DIRS)
$(TARGET) : $(XX_OBJECTS) $(CC_OBJECTS) $(TEST_CASE_O) gtest_main.a
$(XX) $(CXXFLAGS2) $^ -o $@ $(LINK_LIB)
#删除代码目录的 *.gcda,*.gcno和*.o文件
SUBDIRS = $(USER_DIR)/myListeners $(USER_DIR)/myResponsers $(USER_DIR)/logout
GCDA_FILES = $(foreach dir, $(SUBDIRS), $(wildcard $(dir)/*.gcda))
GCNO_FILES = $(foreach dir, $(SUBDIRS), $(wildcard $(dir)/*.gcno))
OBJS_FILES = $(foreach dir, $(SUBDIRS), $(wildcard $(dir)/*.o))
rm -rf $(TARGET) gtest.a gtest_main.a *.o *.gcno *.gcda *.info lcov_out/* \
$(GCDA_FILES) $(GCNO_FILES) $(OBJS_FILES)
执行完后也会在生成gcon文件的目录下生成gcda文件。
（6）最后把测试的命令（1~5）命令写到run.sh脚本里，执行./run.sh就ok了。
#! /bin/bash
make clean
cd ./gtest_lcov
make clean
sudo rm -rf ./lcov_out/*
./appMain./lcov-1.11/bin/lcov -d ../ -t 'appMain' -o'appMain.info' -b . -c
./lcov-1.11/bin/genhtml appMain.info --quiet --output-directory lcov_out--title "appMain"
firefox ./lcov_out/index.html
（7）覆盖率统计图表：
至此，gtest单元测试工具和lcov覆盖率统计工具的结合使用介绍完毕，共同学习进步。
没有更多推荐了，使用Google Test的一个简单例子(接合上一篇看)
本例是从 gtest-1.5.0 自带的 sample 中的 sample1 改写而来，笔者只添加了一个求 n 的阶层的函数，如下。
void Factorial(int n, int & result )
result = 1;
for (int i = 1; i &= i++)
目的是想像这样将返回值放在参数中返回的函数。
对于该函数，添加的单元测试代码如下。
TEST (FactorialTest , Mytest )
int result = 0;
Factorial (5, result);
EXPECT_EQ (120, result);
1. 要测试的代码
要测试的代码 (Sample.h) 代码如下。
要测试的代码 (Sample.cpp) 代码如下。
2. 单元测试代码
单元测试代码 (test.cpp) 如下。
3.1 Linux 平台
makefile 文件，请参考
3.2 Win32 平台
Make.bat 文件，请参考 。
4. 运行结果
4.1 Linux 平台
运行结果如下。
Running main() from gtest_main.cc
[==========] Running 7 tests from 2 test cases.
[----------] Global test environment set-up.
[----------] 4 tests from FactorialTest
] FactorialTest.Negative
OK ] FactorialTest.Negative (0 ms)
] FactorialTest.Zero
OK ] FactorialTest.Zero (0 ms)
] FactorialTest.Positive
OK ] FactorialTest.Positive (0 ms)
] FactorialTest.Mytest
OK ] FactorialTest.Mytest (0 ms)
[----------] 4 tests from FactorialTest (0 ms total)
[----------] 3 tests from IsPrimeTest
] IsPrimeTest.Negative
OK ] IsPrimeTest.Negative (0 ms)
] IsPrimeTest.Trivial
OK ] IsPrimeTest.Trivial (0 ms)
] IsPrimeTest.Positive
OK ] IsPrimeTest.Positive (0 ms)
[----------] 3 tests from IsPrimeTest (0 ms total)
[----------] Global test environment tear-down
[==========] 7 tests from 2 test cases ran. (0 ms total)
] 7 tests.
7 个测试均通过。
4.2 Win32 平台
运行结果如下。
Technorati 标签:
网址：http://blog.csdn.net/livelylittlefish/article/details/6148171
没有更多推荐了，Google C++ unit test 在ARM Android 2.3 上的编译与使用
Google C++ unit test 是一款很不错的单元测试工具，易于构建单元测试例。我们在项目中也使用了此款工具，本文主要描述如何在ARMAndroid 2.3 环境下编译及使用googleC++ unit test 工具。本文假设读者已具备googleC++ unit test相应的基本知识。 如需了解基本知识，请参阅
我们项目所用的编译器：arm-linux-androideabi-g++及其相应工具链
从处获取gtest-1.6.0.zip
下载解压后，需更新build-aux目录下的 config.sub 。此为必须，否则将不能识别arm-linux-androideabi工具链。Config.sub可从 获取。
然后执行./configure –host= arm-linux-androideabi
此后会生成Makefile 文件， 接着我们需要编辑Makefile文件， 改动CXXFLAGS为
CXXFLAGS = -g -O2 –DANDROID
。 此为必须，否则编译不能通过。
最后执行make ，
在lib/.lib/目录下生成了libgtest.a文件。
假设项目只有两个文件: a.cpp；main.cpp 。
a.cpp 为主要被测文件，为此我们创建了一个测试文件，其中包含对a.cpp的测试例，命名为a_unittest.cpp。
修改main函数为如下：
Int main(int argc, char *argv[])
testing::InitGoogleTest(&argc,argv);
returnRUN_ALL_TESTS();
修改被测项目的Makefile ，一使其包含gtest的include目录。二使其在link时，需加上libgtest.a文件，即最终可执行文件应为如下link而成： a.o + main.o
+ a_unittest.o+ libgtest.a
运行此可执行文件即为运行单元测试例
没有更多推荐了，[SoftwareTesting][UnitTest][初级]VC++ 2008 Google Test：gtest 测试项目与正式项目分离方案
1、VC++ 环境下测试项目与正式项目混杂的弊端
测试项目和正式项目无法共存无法独立运行测试项目或者正式项目
图 1 ：测试与正式项目混杂
2、测试项目与正式项目分离方案
Visual Studio 集成环境并不像 Linux 下的构建方式那样来的方便， 可以直观的使用 Make 或 Auto Tool 构造自己需要的编译方式，让多个项目相互协作，互不干扰。但是， VS 中通过在各个配置界面中的配置，也是可以用简单且很不直观的方式实现测试项目与正式项目的分离。
初始的混杂方案如上图 1 所示，请参考： 进行项目的创建。接下来进行测试与正式项目的分离。
2.1、新建 gtest 测试项目
在解决方案中新建 Win32 控制台应用程序， 名称：gtest，解决方案：填入解决方案，不使用预编译头，空项目。
图 2：添加 gtest 项目后解决方案结构
图 3：gtestSample 解决方案目录结构
2.2、剪切测试相关文件到 gtest 项目
剪切 gtestSample 项目中的 sample1_unittest.cc、gtest_main.cc 到 gtest 项目源文件目录中，并将它们添加到 gtest 项目中。
图 4：添加测试相关文件到 gtest 项目
2.3、配置 gtest 项目
此时 gtest 项目还不能引用到 gtestSample 项目的头文件 “sample1.h”，右击 gtest 项目-& 属性-& 配置属性-& C/C++-& 常规-& 附加包含目录：../gtestSample。
图 5：gtest 附加包含目录配置
此时生成解决方案，会出现大量的“error LNK2001: 无法解析的外部符号”连接错误，还需要将 gtestSample 项目中被引用到的文件添加到 gtest 项目中，即添加 “sample1.cc” 到 gtest 项目。
同时，要给 gtest 项目添加附加依赖项：gtestd.lib，因为现在是 gtest 项目执行测试。
图 6：代码分离初步完成
此时生成解决方案还会有“项目: gtestSample：MSVCRTD.lib(crtexe.obj) : error LNK2019: 无法解析的外部符号 _main，该符号在函数 ___tmainCRTStartup 中被引用”的链接错误。这是由于 gtestSample 为 "应用程序(.exe)"的配置，所以给 gtestSample 项目增加一个包含 main() 入口函数的 main.cc 文件。
#include &iostream&
#include "sample1.h"
int main(int argc, char * argv[])
std::cout && "3 is prime ? " && IsPrime(3) && std::
std::cout && "4 is prime ? " && IsPrime(4) && std::
此时方可编译成功，测试一下。
图 7：运行 gtest 项目结果
图 8：运行 gtestSample 项目结果
大公告成，正式项目与测试项目相辅相成，互不干扰~~
编辑记录：
完成混杂弊端说明，分离方案前述。
没有更多推荐了，如何使用GTest对Qt工程代码做unit test（在ubuntu环境下）
最近，笔者参与开发了一个项目，在ubuntu环境下使用qt作为UI framework开发手机上的应用程序，工程也是用qtcreator创建的。
作为程序开发者来说，开发出的功能不仅要符合需求，而且需要保证代码的健壮性，这就需要对所开发的代码做单元测试。
在本文中，笔者将会介绍一下如何使用gtest（即google test）来对已有的Qt工程代码做单元测试。
关于gtest的知识，笔者推荐《玩转Google开源C++单元测试框架Google Test系列(gtest)》系列，链结如下：
下面是笔者的目录结构图，读者可以根据自己的目录结构对本文中出现的配置文件进行修改。
下载安装QtSDK，里面包含qtcreator工具。下载路径：
笔者下载的是liunx下的4.8版本。文件名为：
Qt_SDK_Lin32_offline_v1_2_en.run
下载gtest包。下载路径：
笔者下载的是1.6.0版本，包名为：gtest-1.6.0
三．安装QtSDK
修改安装文件的属性，使之可执行
chmod +x Qt_SDK_Lin32_offline_v1_2_en.run
./ Qt_SDK_Lin32_offline_v1_2_en.run
按提示步骤安装完成QtSDK
qtcreator 将会被安装在 ~/QtSDK/QtCreator/bin/qtcreator目录下，进入该目录
执行qtcreator即可打开qtcreator，利用该IDE可以创建qt的工程。
四． 创建一个qt示例工程
(这里，我创建了一个比较简单的不带UI界面的Qt 控制台应用当做例子)
打开qtcreator， 选择“文件”-&“新建工程或文件“, 在模板里选择”其他项目”，然后在右边的选择框里选择”Qt 控制台应用”， 然后确定工程名称(我的工程名为
qt_test_app)和工程路径，后面的选项一路默认就行了。
执行完成，最后会生成一个Qt工程qt_test_app
该工程里只有一个文件main.cpp，qtcreator已经产生了部分代码。
新建并添加addTest.h和 addTest.cpp 到工程中
在工程名qt_test_app上点击右键，选择“添加新文件”，选择“c++ 头文件”
点击 “选择”，
输入文件名，点击下一步
选择将文件添加到qt_test_app.pro项目里。点击“完成”，文件添加完毕。
使用同样方法创建addTest.cpp文件（新建文件时，需选择c++源文件），也将其添加至qt_test_app.pro工程里。
addTest.h 代码如下：
#ifndef ADDTEST_H
#define ADDTEST_H
class addTest
addTest();
~addTest();
int add(int a, int b);
#endif // ADDTEST_H
(2) addTest.cpp代码如下：
#include "addTest.h"
addTest::addTest()
addTest::~addTest()
int addTest::add(int a, int b)
return (a+b);
main.cpp代码如下：
#include &QtCore/QCoreApplication&
#include "addTest.h"
#include &QtCore/QDebug&
int main(int argc, char *argv[])
QCoreApplication a(argc, argv);
int result = test.add(5, 10);
qDebug()&&"result = "&&
return a.exec();
4. 在pro工程文件目录下执行qmake，生成makefile
5. 编译运行工程
可以在Application Output窗口里看到输出
result = 15
ok， qt 示例工程创建完毕。接下来就要演示如何使用gtest来对它的代码进行单元测试了。
五． 编译libgtest.a包
解压gtest包
unzip gtest-1.6.0.zip
cd gtest-1.6.0
./configure
gtest-1.6.0不需要make install，我们只是使用gtest的库。
编译libgtest.a包（这个包包含了gtest的核心，将来会被用于qt工程的单元测试中）
将脚本build_gtest.sh放到与gtest-1.6.0同一级的目录下。
执行该脚本
./build_gtest.sh
执行成功后，可在gtest-1.6.0/lib目录下看到libgtest.a包已经生成。
脚本内容如下：
cd gtest-1.6.0
g++ -I./include -I./ -c ./src/gtest-all.cc
ar -rv libgtest.a gtest-all.o
#这一步就是生成libgtest包
mv -f libgtest.a lib/
rm gtest-all.o
六．创建qt Test工程，并且在其中使用gtest来对qt_test_app工程做单元测试
创建TestCases工程，工程TestCases.pro文件内容如下：
include (../QtTestProject/qt_test_app/qt_test_app.pro)
DESTDIR = .
OBJECTS_DIR = .obj
QtTestAppDir = ../QtTestProject/qt_test_app
TEMPLATE = app
DEPENDPATH += . $$QtTestAppDir
INCLUDEPATH += . ../gtest-1.6.0/include ../gtest-1.6.0/include/gtest ../gtest-1.6.0/include/gtest/internal \
$$QtTestAppDir
LIBS += -L../gtest-1.6.0/lib –lgtest
#这一句就是把gtest的包包含进来，使用libgtest.a包来做单元测试的
#Test cases
SOURCES += \
main_test.cpp \
HEADERS +=
SOURCES -= main.cpp
#去除qt_test_app工程里面的main.cpp文件，以免出现TestCase工程里有两个main()的错误。
此project文件内容完全根据我自己的目录结构来写的，读者可以根据自己的目录结构进行修改，如果不太清楚pro工程文件里面的各项内容的意思，可以参考以下链接：
在pro文件目录下，执行qmake，生成makefile
用qtcreator 打开该工程，就会看到qt-test-app工程已经包含在了TestCases工程里。
新建并添加新文件main_test.cpp到工程TestCases里面（参考第四步）
在main_test.cpp里添加测试代码，用来测试qt_test_app工程里的addTest类的成员函数add()
main_test.cpp的代码如下：
#include &gtest/gtest.h&
#include &QtCore/QCoreApplication&
#include "addTest.h"
class QtAppEnvironment: public testing::Environment
QtAppEnvironment(int argc, char ** argv)
:m_argc(argc),
m_argv(argv)
virtual void SetUp()
app = new QCoreApplication(m_argc,m_argv);
virtual void TearDown()
app-&exit();
delete app;
QCoreApplication *app;
int m_argc;
char **m_argv;
int main(int argc, char ** argv)
testing::AddGlobalTestEnvironment(new QtAppEnvironment(argc, argv));
testing::InitGoogleTest(&argc,argv);
return RUN_ALL_TESTS();
TEST(addTestCase, Handleadd1)
EXPECT_EQ(2, test.add(1,1));
TEST(addTestCase, Handleadd2)
EXPECT_EQ(10, test.add(2,9));
//test2， 故意把expect的值设为错的
编译运行TestCases工程，Application Output窗口里输出
Ok, 可以看到我们设置的两个测试用例，一个成功，一个失败了。
至此，我们应该已经了解了如何使用gtest来对qt工程里的代码做单元测试了。
欢迎提出疑问，谢谢。
没有更多推荐了，}