首页 > 代码库 > Google Test测试框架分析

Google Test测试框架分析

2024-07-06 09:27:17 232人阅读

Google Test测试框架分析

一、简介

Google Test是由Google主导的一个开源的C++自动化测试框架，简称GTest。GTest基于xUnit单元测试体系，和CppUint类似，可以看作是JUnit、PyUnit等对C++的移植。

下图是GTest测试框架的测试过程，表示的是GTest的两种测试方式。

下面将使用一个极其简单的例子表示xUnit测试的主要过程。如对Hummer的CTXString类的成员方法GetLength进行测试。详见下面GTest代码和注释说明。

// Gtest使用的头文件

#include "gtest/gtest.h"

// 测试对象所需的头文件

#include "Common/Include/Stdtx.h"

#include "Common/Include/TXString.h"

// 定义一个CTXString_Test_NormalStr测试用例，并属于CTXSting_GetLength Test Suit

TEST( CTXString_GetLength, CTXString_Test_NormalStr)

{

CTXString strTest(_T("XXXXXXXX"));

ASSERT_EQ(8,strTest.GetLength());

}

int main( int argc, char **argv )

{

::testing::InitGoogleTest( &argc, argv ); // Gtest测试框架初始化

return RUN_ALL_TESTS(); // 执行所有测试

}

从上面的代码中，可以看出xUint使用的是基于断言的方法，将测试对象执行结果与预期结果进行比较，并得到测试结果。

后续的部分，将从各个方面对GTest测试框架进行分析和评价，并对其部分特性进行分析。

二、GTest测试能力

1. 断言

由于GTest使用的是基于宏定义的方法执行测试命令。故宏断言的使用灵活性是其测试能力的重要标准之一。GTest支持的断言如下表所示：

断言描述	GTest宏举例	GTest	CppUint
基本断言，判断语句为真/假	ASSERT_TRUE	√	√
二元操作断言，断言> >= <= < = !=	ASSERT_GT	√	√
字符串比较（支持宽字符串）	ASSERT_STREQ	√
断言语句抛出/不抛出特定的异常	ASSERT_THROW	√	√
浮点数比较（指定阈值）	ASSERT_FLOAT_EQ	√	√
Windows的HRESULT类型	ASSERT_HRESULT_FAILED	√
断言类型是否相同	StaticAssertTypeEq<T1, T2>	√
自定义断言	略	√

注：CppUint版本为1.10.2，GTest版本为1.5.0。

通过上表的比较可以看出GTest支持的断言的方式有多种多样，十分灵活；其中自定义断言的方式更是其亮点，这将在第四部分"可扩展性"介绍。

为了在断言中获取更多的错误信息，GTest提供了以下3种方式：

使用内置的boolean函数

如果被测函数返回boolean类型，则可以使用以下断言来获取更多的错误信息

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
...	...	...

使用返回AssertionResult类型的函数

使用GTest提供的::testing::AssertionResult类型来自定义函数，做到输出更详细的错误信息。

使用谓词格式化

有些参数不支持<<输出到标准流，那么可以使用自定义谓词格式化函数来输出丰富的错误信息。函数格式如下：

::testing::AssertionResult PredicateFormattern(const *expr1, const char*expr2, ... const char*exprn, T1val1, T2val2, ... Tnvaln);

2. 测试私有代码

对于一般的接口测试，都基于黑盒测试原则，即只测试其公共接口。我们第一部分的GTest测试流程的左分支和CTXTring测试的例子都是基于这个原则。但是在有些时候，还是需要打破类的封装，对其内部的私有代码进行测试，GTest在设计上也为这种测试提供了便利的途径，看下面的例子。

// foo.h 测试对象类Foo的头文件

#include "gtest/gtest_prod.h"

// Defines FRIEND_TEST.

class Foo {

private:

FRIEND_TEST(FooTest, BarReturnsZeroOnNull); // 添加友元测试类

int Bar(void* x); // 被测试的内部接口

};

// foo_test.cc 定义测试用例

TEST(FooTest, BarReturnsZeroOnNull)

{

Foo foo;

EXPECT_EQ(0, foo.Bar(NULL));

}

三、GTest自动化测试

对于一个测试自动化框架，主要通过三个方面对其进行评估，分别是数据驱动，测试结果和异常处理。

1. 数据驱动能力

xUnit的特点是，对于测试用例的数据，使用与测试对象所使用的一致的程序语言来表示。这样做的优点是，数据的定义方式灵活，特别是抽象数据类型可以在代码中直接定义。但是缺点却很明显：一是测试用例过多的时候，测试数据的定义会增大编码的工作量；二是测试用例维护管理比较麻烦；且每次修改测试用例的数据，都测试程序都需要重新编译。

对于第一个问题，GTest使用了三种方法来克服，分别是测试固件类（Test Fixture）、值参数化测试（Value-Parameterized Test）和类型参数化测试（Type-Parameterized Test）

测试固件类

测试固件类可以使得不同的测试共享相同的测试数据配置。仍然通过一个简单的例子和注释来说明。

//测试对象ComparePointer

bool ComparePointer( int *p1, int *p2 )

{

if( p1 == p2 )

return true;

return false;

}

//测试对象GetOffset

long int GetOffset( int * baseAddr , int * Addr )

{

return (long int)( baseAddr - Addr);

}

//定义fixture

class SimpleTestFixture : public ::testing::Test {

protected:

virtual void SetUp() {

p1 = new int;

p2 = new int;

}

virtual void TearDown() {

delete p1;

delete p2;

}

int *p1;

int *p2;

};

//使用Fixture定义Test Case

TEST_F( SimpleTestFixture, TestCase_ComparePointer )

{

ASSERT_FALSE( ComparePointer(p1,p2));

}

//使用Fixture定义Test Case

TEST_F( SimpleTestFixture, TestCase_GetOffset )

{

ASSERT_EQ( GetOffset(p1,p2) , p1-p2);

}

所有的fixture的定义都必须继承::testing::test类，该类其实就是一个接口，定义了SetUp和TearDown接口函数对负责测试用例执行前后环境的生成和撤销。

Fixture类其实是xUnit处理这类问题的经典的方法，下面介绍的两种的方法则是GTest特有。

值参数化测试

值参数化测试和Fixture类的作用类似，也是使得不同的测试共享相同的测试数据配置，但是略有不同。看下面CTXString的例子和注释。

// Type-Parameterized

class CTXString_ParamTest : public ::testing::TestWithParam<const WCHAR*>

{

};

//参数定义

INSTANTIATE_TEST_CASE_P(InstantiationName, CTXString_ParamTest,

::testing::Values( L"XXXXXXX", L"XLLLLLL", L"X654432"));

//使用参数测试CTXString::GetLength

TEST_P(CTXString_ParamTest, CTXString_GetLength_Test )

{

CTXString strTest( GetParam());

ASSERT_EQ(7,strTest.GetLength());

}

//使用参数测试CTXString::GetAt

TEST_P(CTXString_ParamTest, CTXString_GetX_Test )

{

CTXString strTest( GetParam() );

ASSERT_EQ( L‘X‘, strTest.GetAt(0) );

}

（3）类型参数化测试

类型参数化测试，和值参数化测试相似，不同的是用类型来作为参数，故需要使用模板技术来实现。其优点是可以对操作类似或者相同的类型，使用一个Fixture模板来实现所有类的测试用例。看下面的例子和注释。

//测试对象定义

virtual class SimpleBase{

public:

int GetZero();

};

class SimpleTypeA : public SimpleBase{

public:

int GetZero(){

return 0;

}

};

class SimpleTypeB : public SimpleBase {

public:

int GetZero() {

return 1-1; //仅仅是示例，无视它

}

};

//定义一个Fixture模板

template <class T>

class SimpleTypeFixture : public testing::Test {

protected:

SimpleTypeFixture() { ParamPtr = new T;}

virtual ~SimpleTypeFixture() {}

T *ParamPtr;

};

// 枚举所有需要测试的类型，作为参数，这里两个类型为SimpleTypeA/B

typedef testing::Types<SimpleTypeA, SimpleTypeB> TypeToPass;

TYPED_TEST_CASE(SimpleTypeFixture, TypeToPass );

//定义SimpleTypeA/B类GetZero接口的测试用例

TYPED_TEST(SimpleTypeFixture, GetZeroTest)

{

ASSERT_EQ( 0 , this->ParamPtr->GetZero() );

}

上面的三种机制可以使得在编写测试程序的时候减少代码量，解决前面提到的第一个问题。但是，GTest目前仍然没有提供一套内置的完整的数据驱动机制，故仍存在测试用例和测试数据维护管理麻烦等问题。

2. 测试结果

（1）标准测试结果

GTest的测试结果支持两种输出方式，Console和XML文件的格式。GTest在默认情况下都是以Console的形式输出；输出的内容包括测试用例的执行结果和时间，以及一个结果总结。下图是一个GTest测试的结果。

如果需要GTest以XML文件的格式输出，必须在执行测试程序的时候增加参数。假设的你的GTest程序名为gtest_test_demo，则下面的例子将测试结果以XML文件的格式输出到C:/TestResult.xml

gtest_test_demo.exe --gtest_output=xml:C:/TestResult.xml

下图是一个XML输出的例子，同样包括了测试结果和测试时间，而且以Test Suit和Test Case多层次来展示。

<?xml version="1.0" encoding="UTF-8"?>

</testsuite>

</testsuites>

自定义测试结果

在以XML格式的文件输出结果时，还可以使用RecordProperty函数增加一个键值。如在测试用例中执行

RecordProperty("AKey",89);

则最后输出的XML文件为

<?xml version="1.0" encoding="UTF-8"?>

</testsuite>

</testsuites>

GTest还提供了定义测试结果输出方式的结果，详细的介绍在第四部分"可扩展性"。

3. 测试异常

在某些测试场合，使用断言的方式执行某一条测试语句的时候，可能会导致测试程序的出现致命的错误，甚至是导致程序崩溃。由于GTest设计的初衷是为了广泛支持个种平台，甚至是异常处理被禁用的系统，故GTest的代码中都没有使用异常处理机制。故，为了保证测试不会由于某条测试语句的异常而退出，GTest提出了一种"死亡测试"的机制，所谓死亡测试，就是只测试本身会导致测试进程异常退出。

支持死亡测试的宏：

Fatal assertion	Nonfatal assertion	Verifies
ASSERT_DEATH(statement, regex`);	EXPECT_DEATH(statement, regex`);	statementcrashes with the given error
ASSERT_DEATH_IF_SUPPORTED(statement, regex`);	EXPECT_DEATH_IF_SUPPORTED(statement, regex`);	if death tests are supported, verifies that statement crashes with the given error; otherwise verifies nothing
ASSERT_EXIT(statement, predicate, regex`);	EXPECT_EXIT(statement, predicate, regex`);	statementexits with the given error and its exit code matches predicate

下面以一个例子来展示死亡测试的作用，如要测试一个AbortExit是否按照所设计的一样，让程序异常退出。

void AbortExit( )

{

fprintf(stderr,"A Designed FAIL");

abort();

}

// 第一种方法

TEST(MyDeathTest, AbortExit1) {

EXPECT_DEATH( AbortExit(), "A Designed FAIL");

}

// 第二种方法，显式制定退出的类型

TEST(MyDeathTest, AbortExit2) {

EXPECT_EXIT( AbortExit(), testing::ExitedWithCode(3), "A Designed FAIL");

}

死亡测试的实现，其实是使用创建进程来执行将要的测试的语句，并最后回收测试进程的执行结果，由于测试进程和GTest进程是互相独立的，故测试进程的崩溃并不会对GTest进程导致不良的影响。

四、可扩展性

1. 自定义断言

GTest提供了一定的接口，可以支持对断言进行一定的设置，也就是提供了一定程度上的自定义断言的机制。如定义一个比较两个数是否是互为相反数：

bool MyOppNumHelper( int v1, int v2 )

{

return v1+v2 == 0;

}

#define ASSERT_OPPNUM( v1, v2 ) \

ASSERT_PRED2( MyOppNumHelper, v1, v2 )

这里使用的主要的宏是ASSERT_PRED2，后面的2表示的是宏接受2个变量，同样的存在的宏有ASSERT_PRED1、ASSERT_PRED3、ASSERT_PRED4等等。

全局运行环境重载

使用Fixture类可以对每单独一个Test Case的执行环境进行设置，类似的，GTest提供了一个全局环境的设置方法，对应的类由Fixture变为Environment，其定义为

class Environment {

public:

// The d‘tor is virtual as we need to subclass Environment.

virtual ~Environment() {}

// Override this to define how to set up the environment.

virtual void SetUp() {}

// Override this to define how to tear down the environment.

virtual void TearDown() {}

};

下面是一个简单的例子说明该类的作用

class MyEnv : public ::testing::Environment

{

public:

MyEnv(){}

~MyEnv(){}

void SetUp(){

printf("Printf before GTest begins.\n");

}

void TearDown(){

printf("Printf after GTest terminates.\n");

}

};

int main(int argc, char **argv)

{

::testing::InitGoogleTest(&argc, argv);

::testing::AddGlobalTestEnvironment(new MyEnv); //注册一个Environment，可以注册多个

return RUN_ALL_TESTS();

}

// 下面定义一个简单的测试用例，如果没有测试用例存在，Environment不会被使用

TEST( DoNothingTest, NothingTest){}

3. 事件机制

GTest事件机制提供了一套API可以让使用者获得测试过程进度或者测试失败的情况，并对其响应。事件机制提供了两个类，分别为TestEventListener和EmptyTestEventListener，前者是一个接口类，后者是一个对TestEventListener接口的成员的空操作实现。提供EmptyTestEventListener是为了方便用户，在只需要监听某一个事件时，不必重新实现所有的接口函数。TestEventListener的定义如下，

class TestEventListener {

public:

virtual ~TestEventListener() {}

// Fired before any test activity starts.

virtual void OnTestProgramStart(const UnitTest& unit_test) = 0;

// Fired before each iteration of tests starts. There may be more than

// one iteration if GTEST_FLAG(repeat) is set. iteration is the iteration

// index, starting from 0.

virtual void OnTestIterationStart(const UnitTest& unit_test,

int iteration) = 0;

// Fired before environment set-up for each iteration of tests starts.

virtual void OnEnvironmentsSetUpStart(const UnitTest& unit_test) = 0;

// Fired after environment set-up for each iteration of tests ends.

virtual void OnEnvironmentsSetUpEnd(const UnitTest& unit_test) = 0;

// Fired before the test case starts.

virtual void OnTestCaseStart(const TestCase& test_case) = 0;

// Fired before the test starts.

virtual void OnTestStart(const TestInfo& test_info) = 0;

// Fired after a failed assertion or a SUCCESS().

virtual void OnTestPartResult(const TestPartResult& test_part_result) = 0;

// Fired after the test ends.

virtual void OnTestEnd(const TestInfo& test_info) = 0;

// Fired after the test case ends.

virtual void OnTestCaseEnd(const TestCase& test_case) = 0;

// Fired before environment tear-down for each iteration of tests starts.

virtual void OnEnvironmentsTearDownStart(const UnitTest& unit_test) = 0;

// Fired after environment tear-down for each iteration of tests ends.

virtual void OnEnvironmentsTearDownEnd(const UnitTest& unit_test) = 0;

// Fired after each iteration of tests finishes.

virtual void OnTestIterationEnd(const UnitTest& unit_test,

int iteration) = 0;

// Fired after all test activities have ended.

virtual void OnTestProgramEnd(const UnitTest& unit_test) = 0;

};

下面使用一个来自GTest文档的例子说明事件的使用方法和带来的好处。

class MinimalistPrinter : public ::testing::EmptyTestEventListener {

// Called before a test starts.

virtual void OnTestStart(const ::testing::TestInfo& test_info) {

printf("*** Test %s.%s starting.\n",

test_info.test_case_name(), test_info.name());

}

// Called after a failed assertion or a SUCCEED() invocation.

virtual void OnTestPartResult(

const ::testing::TestPartResult& test_part_result) {

printf("%s in %s:%d\n%s\n",

test_part_result.failed() ? "*** Failure" : "Success",

test_part_result.file_name(),

test_part_result.line_number(),

test_part_result.summary());

}

// Called after a test ends.

virtual void OnTestEnd(const ::testing::TestInfo& test_info) {

printf("*** Test %s.%s ending.\n",

test_info.test_case_name(), test_info.name());

}

};

int main(int argc, char **argv)

{

::testing::InitGoogleTest(&argc, argv);

// Gets hold of the event listener list.

::testing::TestEventListeners& listeners =

::testing::UnitTest::GetInstance()->listeners();

// Adds a listener to the end. Google Test takes the ownership.

listeners.Append(new MinimalistPrinter);

return RUN_ALL_TESTS();

}

TEST( DoNothingTest, NothingTest){}

上面的例子实现的就是一个简单的GTest结果输出引擎，上面指捕获了三个事件TestStart、TestEnd和TestPartResult，但是由于测试结果就是在这几个时间点上报告，故已经足够了。

其实，在GTest内部，无论是Console输出和XML结果输出，也是使用事件机制来实现的。使用同样的方法，可以使GTest按照你自己的意愿处理测试结果，如将结果记录到某一个远程数据库或一个本地文本文件。当然，事件机制还远远不止可以做到这些事情。

五、其他特性

1. 分布式测试

GTest支持在多机器上并行执行同一个Test Suit的测试用例。下面用一个简单的例子说明，假设下面的测试用例，包含两个Test Suit：A和B。

TEST(A, V)
TEST(A, W)
TEST(B, X)
TEST(B, Y)
TEST(B, Z)

并假设我们有三台独立的机器，故在每台机器上设置环境变量GTEST_TOTAL_SHARDS制定机器的数目。（GTest将该分布式测试命名为Sharding，并把一个测试机器叫做Shard。）对于不同的Shard，还必须设置另一个环境变量GTEST_SHARD_INDEX；该变量的值每一个Shard都必须不同，且范围是0到GTEST_TOTAL_SHARDS的值减1。

设置好每个shard的环境变量后，就可以在所有的机器上执行测试。GTest会根据一定的算法，分配测试用例。如，上面的测试用例分配给三个机器可能为这样。

Machine #0 runs A.V and B.X.

Machine #1 runs A.W and B.Y.

Machine #2 runs B.Z.

GTest测试用例的分配目前是以负载均衡为目标，要求在每个Test Suit中的测试用例尽可能的均匀分布。在GTest使用的其实是一个简单的符合均衡分布的哈希函数实现，其实现如下：

boolShouldRunTestOnShard(inttotal_shards, intshard_index, inttest_id) {

return (test_id % total_shards) == shard_index;

}

ShouldRunTestOnShard是GTest调用用例判断是否执行当前测试用例的函数，total_shards指的是shard的总数，也就是GTEST_TOTAL_SHARDS的值；而shard_index由每个GTest的GTEST_SHARD_INDEX定义。Test_id只得是测试用例的标识符，一般是以0开始递增分布。

目前GTest的Sharding机制仍处于开发的初步阶段，还有很多问题没有解决，如对于最后的测试结果的报告，GTest甚至没有提供任何汇总的机制，虽然用户本身可以自己实现。

2. 作用域跟踪

首先看一个简单的测试用例。

voidFooExpect( intn )

{

EXPECT_EQ(1, n);

//...

//大量重复的操作

}

TEST( FooExpectTest, FooTest )

{

FooExpect(3);

FooExpect(9);

}

很明显，上面的测试用例会存在两个错误报告，输出结果为

main.cpp(199): error: Value of: n

Actual: 3

Expected: 1

main.cpp(199): error: Value of: n

Actual: 9

Expected: 1

可以看出的问题是，虽然两个测试失败，但是报告的错误的地点是一样的，这是由于断言是在函数FooExpect中使用。但是如何找到错误时，函数是在哪里被调用？答案就是使用作用域跟踪，将上面的测试用例修改为

TEST( FooExpectTest, FooTest )

{

SCOPED_TRACE("XXX");

FooExpect(3);

}

{

SCOPED_TRACE("YYY");

FooExpect(9);

}

执行测试后，结果就变为：

main.cpp(199): error: Value of: n

Actual: 3

Expected: 1

Google Test trace:

main.cpp(205): XXX

main.cpp(199): error: Value of: n

Actual: 9

Expected: 1

Google Test trace:

main.cpp(209): YYY

当然，作用域跟踪还可以作为一个函数跟踪来使用，显然，每一个函数都是一个作用域。在有多重的函数嵌套和调用的时候，使用作用域跟踪也不失为一个好方法。

3. 传递严重错误

使用ASSERT的宏断言的机制有一个缺点，就是在错误发生的时候，GTest并没有接受整个错误，而只是中止当前的函数。如下面的例子，在会导致段错误，

voidSubroutine() {

ASSERT_EQ(1, 2); // 产生一个错误

printf("this is not to be executed\n") // 该语句不会被执行

}

TEST(FooTest, Bar) {

Subroutine();

int* p = NULL;

*p = 3; // 访问空指针!

}

解决这个问题的方法是使用错误传递的方法，错误传递的方法有两种，第一个是使用ASSERT_NO_FATAL_FAILURE。

TEST(FooTest, Bar) {

ASSERT_NO_FATAL_FAILURE( Subroutine() );

int* p = NULL;

*p = 3; // 访问空指针!

}

对于第一种方法，只支持Subroutine() 为当前同一个线程的情况。故，对于不同的线程，可以使用第二种方法，使用HasFatalFailure函数来判断当前的测试中是否有经历过断言失败。

TEST(FooTest, Bar) {

Subroutine();

if (HasFatalFailure()) return;

int* p = NULL;

*p = 3; // 访问空指针!

}

GTest、CppUnit和DAT的比较

1. 测试框架比较

下表是三个测试框架的比较总汇。

	GTest	DAT	CppUint
测试用例	Hard code	基于XML文件的数据驱动	Hard code
测试结果	内置Console和XML文件输出	以TXData结构存储，目前支持XML文件输出，且可以自动产生html总结	Console、文本和MFC界面输出
测试方法	xUnit架构，基于断言的方式	自定义测试逻辑，使用Log方式记录	xUnit架构，基于断言的方式
多线程	内置数据结构非线程安全	内置数据结构非线程安全	内置数据结构非线程安全，但提供一定的多线程保护机制
多机测试	初步支持	不支持（计划支持中）	不支持
框架可扩展性	高	一般	一般
执行异常处理	提供"死亡测试"	提供执行超时避免和测试守护进程，支持崩溃自动重启	可以使用C++异常处理实现
面向的使用者	测试驱动开发人员	测试驱动开发人员，测试人员	测试驱动开发人员

对于上面所述的测试框架，CppUint和GTest由于同属于xUnit测试框架族，故比较类似。DAT则与前者有很大的不同。两者的区别可以用下面的图表示，左边表示的是GTest和CppUint，右边的是DAT。

两种体系的最大的不同是：DAT使用接口封装的方法，令测试模块和测试执行的引擎相对分离，且有更加的数据驱动机制，优点是集成性和维护成本低，适合于持续迭代的测试，但是灵活性略有下降。GTest的测试数据和测试逻辑与测试执行引擎耦合性交高，灵活性高。

GTest对DAT的借鉴意义

GTest和DAT有很大的不同，但是有不少的地方DAT可以从中借鉴并得到改进，包括下面几点：
结合断言的方式和DAT本身的测试方法，在原本使用Log的方式记录的基础上，提供一些断言宏，辅助测试命令的编码。

GTest的死亡测试，可以让使用者轻松的创建一个进程来测试不安全的测试，虽然DAT并不需要死亡测试，但是可以提供一个便利的接口，让DAT的使用者可以轻松的创建一个进程来执行一项测试。

七、GTest代码实现技巧浅谈

1. GTest用例自动注册机制

如果细心留意第一部分的简单GTest例子，就可以发现只存在两个结构，一个main函数和使用宏辅助实现的测试用例CTXString_Test_NormalStr。也就是说，GTest编写测试用例的时候，并不需要额外进行注册，GTest会自动识别所以的测试用例。让我们看看GTest是怎么实现的，我们把第一部分的TEST( CTXString_GetLength, CTXString_Test_NormalStr)的宏展开，可以得到：

//测试用例类实现

classCTXString_GetLength_CTXString_Test_NormalStr_Test : public ::testing::Test {

public:

CTXString_GetLength_CTXString_Test_NormalStr_Test() {}

private:

virtualvoidTestBody();

static ::testing::TestInfo* consttest_info_;

//禁止对象复制和赋值

CTXString_GetLength_CTXString_Test_NormalStr_Test(

constCTXString_GetLength_CTXString_Test_NormalStr_Test &);

voidoperator= (CTXString_GetLength_CTXString_Test_NormalStr_Testconst &);

};

//初始化类静态成员test_info_

::testing::TestInfo* constCTXString_GetLength_CTXString_Test_NormalStr_Test::test_info_ =

::testing::internal::MakeAndRegisterTestInfo(

"CTXString_GetLength", "CTXString_Test_NormalStr", "", "",

::testing::internal::GetTestTypeId() ,

::testing::Test::SetUpTestCase,

::testing::Test::TearDownTestCase,

new ::testing::internal::TestFactoryImpl<CTXString_GetLength_CTXString_Test_NormalStr_Test> );

//测试用例执行体

voidCTXString_GetLength_CTXString_Test_NormalStr_Test::TestBody()

{

CTXStringstrTest(_T("XXXXXXXX"));

ASSERT_EQ(8,strTest.GetLength());

}

从展开的宏的代码中可以看出，测试用例类的实现中都设置一个"多余"的静态成员，由于静态成员会在程序初始化阶段被初始化，故甚至在main函数开始执行之前，函数MakeAndRegisterTestInfo会被调用，就如该函数的名称表示的一样，测试用例就是在此处自动注册。可见Google的工程师为GTest的易用性还是下了一番功夫。

2. 类型测试

GTest内部广泛对类型测试的支持，这一点一方面是得益于C++类模板机制，我们来看看其中最简单的类型断言（Type Assertion）。类型断言指的是断言某一个类型与另一个类型是相同的，否则测试在编译时报错。看下面的例子。

template <typenameT> classFoo {

public:

voidBar() { ::testing::StaticAssertTypeEq<int, T>(); }

}

//简单测试，下面会导致编译时报错

//error C2514: ‘testing::internal::StaticAssertTypeEqHelper<T1,T2>‘ : class has no constructors

voidTest2() { Foo<bool> foo; foo.Bar(); }

下面看看StaticAssertTypeEq是怎么实现的。

template <typenameT1, typenameT2>

boolStaticAssertTypeEq() {

internal::StaticAssertTypeEqHelper<T1, T2>();

returntrue;

}

namespaceinternal {

// This template is declared, but intentionally undefined.

template <typenameT1, typenameT2>

structStaticAssertTypeEqHelper;

template <typenameT>

structStaticAssertTypeEqHelper<T, T> {};

} // namespace internal

从上面代码，其中一个模板类只是声明但是没有定义，故尝试调用的时候就会报错。

3. 断言的实现

首先看一个简单的测试用例。

intSubroutine() {

ASSERT_EQ(1, 2); //Line 199

return 0;

}

TEST(FooTest, Bar) {

Subroutine();

}

从代码上看，似乎没有什么问题，但是在编译的时候却会报错。

Error 1: ‘return‘ : cannot convert from ‘void‘ to ‘int‘ : main.cpp(199)

看似问题应该是由于ASSERT导致，所以我们展开这个宏，得到

GTEST_AMBIGUOUS_ELSE_BLOCKER_//防止ASSERT宏被嵌套在其他if-else语句中潜在的问题

if ( const ::testing::AssertionResultgtest_ar

= ::testing::internal::EqHelper<false>::Compare("1","2",1,2) ) //断言检查逻辑

;

else

return ::testing::internal::AssertHelper(::testing::TestPartResult::kFatalFailure,

__FILE__, __LINE__,

gtest_ar.failure_message() )

= ::testing::Message();

代码的重点主要在else分支，也就是断言失败的分支。问题的关键点在AssertHelper类，其声明为

classGTEST_API_AssertHelper {

public:

AssertHelper(TestPartResult::Typetype,

constchar* file,

intline,

constchar* message);

~AssertHelper();

voidoperator=(constMessage& message) const; //断言消息流支持

private:

//这里省略部分私有成员

//禁止对象复制和赋值

AssertHelper( AssertHelper const &);

voidoperator=(AssertHelper const &);

};

只要从上面的代码中就可以看到，由于类重载了赋值操作符，且返回类型为void。所以，很明显，GTest的断言必须存在于返回类型为void的函数中。从代码中还可以知道AssertHelper类对象是不可以复制和被用作于赋值的，故这里的AssertHelper对象的唯一作用就是，将断言的消息填充到消息流中。

声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉：投诉/举报工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。

联系
我们

首页 > 代码库 > Google Test测试框架分析