Googletest高级使用指南

GoogleTest框架高级使用指南(一)GoogleTest写一些测试程序,现在是学习更多技巧的时候了。这篇文章将告知你更多的断言、如何用流传递简洁的错误信息、传达致命失败、重用并加快你的测试夹具以及在你的测试工程中使用各种的标记。GoogleTestPrimer并学会了如何用GoogleTest写一些测试程序,现在是学习更多技巧的时候了。这篇文章将告知你更多的断言、如何用流传递简洁的错误信息、传达致命失败、重用并加快你的测试夹具以及在你的测试工程中使用各种的标记。更多断言本节包括一些不太常用的，但照旧很有意义的断言。明确声明成功或失败也可以为它们自定义失败信息。SUCCEED;SUCCEED;没有消灭失败的断言。自定义输出功能。FAIL;FAIL;ADD_FAILURE;FAIL*生成一个致命失败，而ADD_FAILURE*则产生一个非致命失败。相对于布尔表达式，它们在把握流程时会更有用。例如，你可以象这样写：switch(expression){case1:...somechecks...case2:...someotherchecks4. ...5. default:FAIL<<“Weshouldn”tgethere.“;6. }:Linux,Windows,Mac.特别断言以下断言用于测试一片代码是否会抛出指定类型的特别:致命断言致命断言非致命断言验证工程ASSERT_THROW(statement,exception_type);EXPECT_THROW(statement,exception_type);excep的特别ASSERT_ANY_THROW(statement);EXPECT_ANY_THROW(statement);statement抛出一个特别ASSERT_NO_THROW(statement);EXPECT_NO_THROW(statement);statement不会抛出特别例如:1. bar_exception);2.EXPECT_NO_THROW({intn=5;Bar(&n);6. });:Linux,Windows,Mac;sinceversion1.1.0.谓语断言GoogleTest有一系列丰富的断言，但它们永久不会足够，由于不行能〔也不是好方法〕去估量用EXPECT_TRUE来检查简洁的表达式，由于没有更好EXPECT_TRUE里。不管怎样，这种方法都令人犯难尤其是目标表达式含有副作用或难以评价时。为了解决这个问题，我们供给了一组通用的谓语断言:致命断言致命断言非致命断言验证工程ASSERT_PRED1(pred1,val1);EXPECT_PRED1(pred1,val1);pred1(val1)trueASSERT_PRED2(pred2,val1,v EXPECT_PRED2(pred2,val1,v pred2(val1,val2)返回al2); al2); true.........在上面的表格中，prednn-个参数的谓语〔函数或函数对象〕val1,val2,...,valn是它的参数。假设在给定的参数下谓语返回真则测试成功，否则失败。当失败时，它会打印出每个参数。在任何状况下，参数只会被评估一次。当前，我们只供给了最多支持5个参数的谓语断言，假设你需要更多的谓语断言，让我们知道。举例来说，假定//Returnstrueiffmandnhavenocommondivisorsexcept1.boolMutuallyPrime(intm,intn){...}constinta=3;constintb=4;constintc=10;EXPECT_PRED2(MutuallyPrime,a,b)成功，而EXPECT_PRED2(MutuallyPrime,b,c)MutuallyPrime(b,c)isfalse,wherebis4cis10(ASSERT|EXPECT)_PRED*产生的信息不能满足你的要求，或一些参数不支持输出到流(ostream)，你可以用下面的可以格式化自定义信息的断言来代替：致命断言致命断言非致命断言验证工程ASSERT_PRED_FORMAT1(pred_fo EXPECT_PRED_FORMAT1(pred_f pred_format1(valrmat1,val1);` ormat1,val1); 1)成功ASSERT_PRED_FORMAT2(pred_fo EXPECT_PRED_FORMAT2(pred_frmat2,val1,val2); ormat2,val1,val2);pred_format2(val1,val2)成功......这组断言和上面的区分在于其谓语的区分，(ASSERT|EXPECT)_PRED_FORMAT*使用predicate-formatter(pred_formatn),这是一个如下形式的函数或函数对象：testing::AssertionResultPredicateFormattern(constchar*expr1,constchar*expr2,...constchar*exprn,T1val1,T2val2,...Tnvaln);,valn是其参数值，expr1,expr2exprnT1,TFoo,FooconstFoo&都可以作为这个谓语的参数。返回testing::AssertionResult 出断言是成功还是失败。这个对象只能通过下面的工厂函数创立：1. namespacetesting{2.//ReturnsanAssertionResultobjecttoindicatethatanassertionhas//succeeded.AssertionSuccess;6.//ReturnsanAssertionResultobjecttoindicatethatanassertionhas//failedwiththegivenfailuremessage.AssertionResultAssertionFailure(constMessage&msg);10.11.}//namespacetesting作为例子，我们来改善前面使用EXPECT_PRED2 的那个例子里的失败信息://Returnsthesmallestprimecommondivisorofmandn,//SmallestPrimeCommonDivisor(intm,intn){...}4.//Apredicate-formatterforassertingthattwointegersaremutuallyprime.testing::AssertionResultAssertMutuallyPrime(constchar*m_expr,constchar*n_expr,intm,intn){if(MutuallyPrime(m,n))returntesting::AssertionSuccess;testing::Messagemsg;10. msg<<m_expr<<“and“<<n_expr<<“(“<<m<<“and“<<n<<“)arenotmutuallyprime,“<<“astheyhaveacommondivisor“<<SmallestPrimeCommonDivisor(m,n);returntesting::AssertionFailure(msg);14.}使用这个predicate-formatter,我们用EXPECT_PRED_FORMAT2(AssertMutuallyPrime,b,c);生成的消息是:bandc(4and10)arenotmutuallyprime,astheyhaveacommondivisor2.你可能已经觉察，我们以前提到的很多断言都只是(EXPECT|ASSERT)_PRED_FORMAT*的一个特例。实际上，它们中的大多数是(EXPECT|ASSERT)_PRED_FORMAT*的调用。EXPECT_PRED*时出在编译错误“nomatchingfunctio,里找解决方法。适用于:Linux,Windows,Mac.浮点数比较浮点数的比较是比较麻烦的，由于舍入误差，两个浮点数准确匹配的可能性不大。因此，ASSERT_EQ0。一般来说，要合理地比较浮点数，就要认真地选择误差范围。假设不想为这个伤神，使用ULPs〔UnitsiTest就供给了这么做的断言。关于ULPs的具体解释thisarticleonfloatcomparison.浮点数比较宏致命断言致命断言非致命断言验证工程ASSERT_FLOAT_EQ(expected,actual);EXPECT_FLOAT_EQ(expected,actual);近似相等ASSERT_DOUBLE_EQ(expected,actual);EXPECT_DOUBLE_EQ(expected,actual);近似相等4ULP”s以内。下面的断言允许你自己选择可承受的误差范围：致命断言致命断言非致命断言验证工程ASSERT_NEAR(val1,val2,abs_error);EXPECT_NEAR(val1,val2,abs_error);abs_er指定确实定误差范围适用于:Linux,Windows,Mac.浮点数的格式化谓语函数化谓语函数，它们可以用在谓语断言(EXPECT_PRED_FORMAT2等)里。EXPECT_PRED_FORMAT2(testing::FloatLE,val1,val2);EXPECT_PRED_FORMAT2(testing::DoubleLE,val1,val2);验证val1小于或近似于val2你也可以用ASSERT_PRED_FORMAT2 代替EXPECT_PRED_FORMAT2。适用于:Linux,Windows,Mac.WindowsHRESULT断言HRESULT成功或失败。致命断言致命断言非致命断言验证工程ASSERT_HRESULT_SUCCEEDEDEXPECT_HRESULT_SUCCEEDED(expression);(expression);expression返回成功的HRESULTASSERT_HRESULT_FAILED(ASSERT_HRESULT_FAILED(expression);EXPECT_HRESULT_FAILED(expression);expression返回失败的HRESULTHRESULTWindows错误信息。你可以这样用：CComPtrshell;ASSERT_HRESULT_SUCCEEDED(shell.CoCreateInstance(L“Shell.Application“));CComVariantempty;empty,empty,empty,empty));适用于Windows.断言的位置)值的函数里使用，这是由于GoogleTest没有使用特别机制。假设在有返回值的函数里使用致命断言你将会得到一个令人迷惑的编译错误：“error:voidvaluenotignoredasitoughttobe“。T2Foo(T1x)voidFoo(T1x,T2*result)result里也有一个有效的值。现在它是无返回值的了，里面也就可以使用全部断言了。ADD_FAILURE*和EXPECT_*。注：依据C++语言标准，构造和析构函数并不是无返回值的函数，所以你也不能在那里使用致命断言。一个简洁解决方法是把构造和析构函数体移到一个无返回值的私有函数里。不管怎样，你应当知道在构造代码里的致命断言并不会终止当前的测试，它只是造成更早地从构造中返回。这可能会使你的对象只构造了留神GoogleTest框架高级使用指南(二)死亡测试(DeathTests)全漏洞或更糟。因此使这些程序段工作在预期状态下是极为重要的。这些检测进程死亡缘由的测试我们称之为死亡测试(deathtests)，更一般地说，任何检查程序是否按deathtest。怎样写DeathTestGoogleTestdeathtests:致命断言致命断言非致命断言验证工程ASSERT_DEATH(statement,regex`);EXPECT_DEATH(statement,regex`);statement以预期的错误崩溃ASSERT_EXIT(statement,predicate,regex`);EXPECT_EXIT(statement,predicate,regex`);statement以预期的错误退出并且错误码匹配predicate这里的statement是一个可能造成进程退出的程序段，predicate是一个函数或函数对象用于评估一何有效的代码段(包括复合语句)。ASSERT系列会退出当前函数而EXPECT系列不会。int参数并返回bool，只有trueDeathTest成功：testing::ExitedWithCode(exit_code)exit_codetrue。testing::KilledBySignal(signal_number)killtrue。0退出码退出或被一个信号杀死的状况。Test，只要在你的测试函数里使用上面的这几个宏就可以了，例如：TEST(My*DeathTest*,Foo){//Thisdeathtestusesacompoundstatement.ASSERT_DEATH({intn=5;Foo(&n);},“Erroronline.*ofFoo“);4. }TEST(MyDeathTest,NormalExit){testing::ExitedWithCode(0),“Success“);7. }TEST(MyDeathTest,KillMyself){ EXPECT_EXIT(KillMyself,testing::KilledBySignal(SIGKILL),“Sendingmyselfunblockablesignal“);10.}:Foo(5)使进程死亡并得到指定的信息。使进程打印“Success“stderr0。KillMyself使用信号SIGKILL杀死进程。假设需要，这些测试函数也可以使用其它断言和代码。:〔不是测试命名成*DeathTest面的例子一样。在死亡测试和线程段会解释为什么要这么做。适用于:Linux它是怎么工作的ASSERT_EXITfork来产生一个进程。接下来这个子进程如何工作依靠于te的变量值(它能过命令行参数--gtest_death_test_style)。“fast“，那么死亡测试马上开头。“threadsafe“，子进程会重执行全部的单元测试，就象原进程做的一样。其它变量值是非法的并会使死亡测试失败。当前，它的默认值是“fast“。不过，我们保存在以后版本中转变它的权利，因此你的测试不应当依靠于它〔默认值〕。不管哪种状况，父进程都会等待子进程完成，并检查：子进程退出码输出的信息假设死亡测试代码段没有引起进程退出而是始终执行完毕，子进程还是会被终止并且返回断言失败。死亡测试和线程理干净。GoogleTest有两个功能用于提示这个线程问题假设死亡测试开头时觉察有多个线程在运行将会发出警告。以“DeathTest“作为测试用例后缀的测试优先于其它测试执行。在死亡测试代码段里建立线程是完全允许的，由于它们在一个子进程里执行因而不会影响到父进程。DeathTestStyles引入“threadsafe“死亡测试形式的目的是为了削减多线程环境里的测试问题。它会合理地添加一点运行时间来加强线程安全。不过我们还是建议使用“fast“形式除非你在测试时遇到了问题。你可以在程序中设置死亡测试形式：testing::FLAGS_gtest_death_test_style=“threadsafe“;GoogleTest会在每次测试之前保存这个标记并在测试完成后恢复，所以你不需要去管这局部工作，如下例：TEST(MyDeathTest,TestOne){testing::FLAGS_gtest_death_test_style=“threadsafe“;//Thistestisruninthe“threadsafe“style:““);5. }6.TEST(MyDeathTest,TestTwo){//Thistestisruninthe“fast“style:ASSERT_DEATH(ThisShouldDie,““);10.}11.intmain(intargc,char**argv){testing::InitGoogleTest(&argc,argv);testing::FLAGS_gtest_death_test_style=“fast“;returnRUN_ALL_TESTS;16.}忠告C++代码，不过它不能从当前函数返回。也就是说〔ASSERT_TRUE〕。假设这段代码在崩溃之Test就会打印出一条错误信息并返回测试失败。〔如，转变变量，释放内存等〕无法在父进程里观看到。这种这个问题，你可以：不要在死亡测试里释放内存。在父进程里再次释放内存。不要在程序中使用内存堆检查。由于实现细节，你不能在一行中放多条死亡测试断言；不然将会显示出一条难以理解的编译错误。“threadsafepthread_atfork之前照旧会消灭。以后版本中会改进这个问题。argv[0]execve函数来重运行。假设程序中有更改当前工作名目的代码那么使用相对路径运行它时可能会消灭找不到执行文件的状况。GoogleTest框架高级使用指南(三)在子程序中使用断言给断言加上“显影之尘”(trace)SCOPED_TRACE宏：SCOPED_TRACE(SCOPED_TRACE(message);message可以是任何允许用std::ostream输出的数据〔不愿定要字符串〕。有效。例如,voidSub1(intn){EXPECT_EQ(1,Bar(n));EXPECT_EQ(2,Bar(n+1));13.}14.15.TEST(FooTest,Bar){16. {17. SCOPED_TRACE(“A“);//这个跟踪点信息会消灭在全部属于它的有效范围内的失败断言里18. Sub1(1);19. }20. //这里不会消灭跟踪点信息了21. Sub1(9);22.}结果输出会象这个样子:path/to/foo_test.cc:11:FailureValueof:Bar(n)Expected:1Actual:2Trace:path/to/foo_test.cc:17:Apath/to/foo_test.cc:12:FailureValueof:Bar(n+1)Expected:2Actual:3假设没有跟踪信息，将很难知道这两次失败是在那次调用里发生的。〔你可以依据它的参数nSub1加上额外的断言信息，只是这样有点乏味〕SCOPED_TRACE的提示一般来说只要输出信息适当的话，在子程序段开头的地方使用SCOPED_TRACE就足够了，而不用放到每个调用它的地方。SCOPED_TRACE代造成的失败了。有时，使用行号就足以区分每次调用，那么你可以简洁地直接使用空白串作为SCOPED_TRACE的参数。Emacs里可以直接点击跟踪信息跳转到相对的代码行里！Linux,Windows,Mac.致命失败的传递常常犯的失误是没有搞清ASSERT_*和FAIL*失败仅仅是退出当前函数，而不是整个测试。举例来说，下面的测试是有问题的：voidSubroutine{//产生一个致命失败退出当前函数。ASSERT_EQ(1,2);//其下代码不会被调用。5. ...6. }7.TEST(FooTest,Bar){Subroutine;产生一个致命失败而退出整个测试//实际状况是：这个函数会连续执行下面的代码int*p=NULL;*p=3;//Segfault!14.}由于我们没有使用特别机制，所以这里不行能达成你想要的这个效果。为了缓解这个冲突，GoogleTest(ASSERT|EXPECT)_NO_FATAL_FAILURE断言或HasFatalFailure函数。断言整个程序段断言的子程序〔并且测试失败〕，这次测试还是会连续下去直到完毕，这可能不是你想要的。通常人们期望致命失败能像特别一样传递出来。soGoogleTest供给了下面的宏：致命断言致命断言非致命断言验证工程ASSERT_NO_FATAL_FAILUREXPECT_NO_FATAL_FAILURstatement不会产生致命失败E(statement);E(statement);〔当前线程〕。只有断言和它处于同一线程时才会执行检查，如查statement建立了一个线程，那么这些线程里的全部失败都被无视。例:1. ASSERT_NO_FATAL_FAILURE(Foo);2.inti;EXPECT_NO_FATAL_FAILURE({i=Bar;6. });Linux,Windows,Mac.当前不支持处理多线程里的断言.在当前测试中检查致命失败是testing::Testtrue。这样就允许提早觉察致命失败并退出。classTest{public:3. ...4. staticboolHasFatalFailure;5. };6.7. 典型的用法是模拟特别机制：8.TEST(FooTest,Bar){Subroutine;//AbortsifSubroutinehadafatalfailure.if(HasFatalFailure)return;//Thefollowingwon”tbeexecuted.15. ...16.}HasFatalFailureTEST,TEST_F或者测试夹具以外使用HasFatalFailure,testing::Test::前缀，象这样：if(testing::Test::HasFatalFailure)return;适用于Linux,Windows,Mac.GoogleTest框架高级使用指南(四)记录额外信息你可以在测试代码中调用RecordProperty(“key“,value)来记录额外的信息，这里的valu32GoogleTestXML数据到你指定的地方，比方下面的测试：TEST_F(WidgetUsageTest,MinAndMaxWidgets){RecordProperty(“MaximumWidgets“,ComputeMaxUsage);ComputeMinUsage);4. }将会输出如下形式：1. ... <testcasename=“MinAndMaxWidgets“status=“run“time=“6“classname=“WidgetUsageTest“MaximumWidgets=“12“MinimumWidgets=“9“/>5. ...留意：TestTEST或测试夹具外部使用它时testing::Test::。GoogleTest使用的重名(name,status、time和classname)。,,Mac.在同一测试用例中共享资源为了使每次测试之间保持无关性以及便于调试的缘由，GoogleTest为每次测试建立一个的测试夹具。但是，有时测试所使用的资源建立起来可能比较“昂贵”，这样为每次测试生成一个资源就显得过于“白费”了。(set-up/tear-down)，GoogleTest也支持针对每个测试用例的设置与回收(set-up/tear-down)：在你的测试夹具〔FooTest〕中定义一些静态(static)成员变量来存放共享资源。staticvoidSetUpTestCase(SetUpTe哦)来设置共享资源，定义staticvoidTearDownTestCase函数来回收共享资源。TestFooTest测试用例的测试前自动调用SetUpTestCFooTestTearDownTestCase，在这之间，这个测试用例的全部测试都共享使用同一资源。何共享资源的状态，或者，转变了共享资源的状态后要在退出其把握范围前恢复。举例：classFooTest:publictesting::Test{protected://Per-test-caseset-up.//Calledbeforethefirsttestinthistestcase.//Canbeomittedifnotneeded.staticvoidSetUpTestCase{shared_resource_=new...;8. }9.//Per-test-casetear-down.//Calledafterthelasttes