linux gtest之primer

Google C++ Testing Framework Primer

 

翻译：Ray Li (ray.leex@gmail.com)
修改日期：2008年7月6日
原文参见：http://code.google.com/p/googletest/wiki/GoogleTestPrimer

翻译原文：http://ray-leex.iteye.com/blog/212024

 

Introduction：为什么需要Google C++ 测试框架？

 

Google C++ 测试框架帮助你更好地编写C++测试。

 

无论你是在Linux，Windows，还是Mac环境下工作，只要你编写C++代码，Google 测试框架都可以帮上忙。

 

那么，哪些因素才能构成一个好的测试？以及，Google C++ 测试框架怎样满足这些因素？我们相信：

  1. 测试应该是独立、可重复的。因为其他测试成功或失败而导致我们要对自己的测试进行debug是非常痛苦的。Google C++ 测试框架通过将每个测试在不同的对象中运行，使得测试分离开来。当一个测试失败时，Google C++ 测试框架允许你独立运行它以进行快速除错。
  2. 测试应该能够被很好地组织，并反映被测代码的结构。Google C++ 测试框架将测试组织成测试案例，案例中的测试可以共享数据和程序分支。这样一种通用模式能够很容易辨识，使得我们的测试容易维护。当开发人员在项目之间转换，开始在一个新的代码基上开始工作时，这种一致性格外有用。
  3. 测试应该是可移植、可重用的。开源社区有很多平台独立的代码，它们的测试也应该是平台独立的。除开一些特殊情况，Google C++ 测试框架运行在不同的操作系统上、与不同的编译器（gcc、icc、MSVC）搭配，Google C++ 测试框架的测试很容易与不同的配置一起工作。
  4. 当测试失败时，应该提供尽可能多的、关于问题的信息。Google C++ 测试框架在第一个测试失败时不会停下来。相反，它只是将当前测试停止，然后继续接下来的测试。你也可以设置对一些非致命的错误进行报告，并接着进行当前的测试。这样，你就可以在一次“运行-编辑-编译”循环中检查到并修复多个bug。
  5. 测试框架应该能将测试编写人员从一些环境维护的工作中解放出来，使他们能够集中精力于测试的内容。Google C++ 测试框架自动记录下所有定义好的测试，不需要用户通过列举来指明哪些测试需要运行。
  6. 测试应该快速。使用Google C++ 测试框架，你可以重用多个测试的共享资源，一次性完成设置/解除设置，而不用使一个测试去依赖另一测试。

因为Google C++ 测试框架基于著名的xUnit架构，如果你之前使用过JUnit或PyUnit的话，你将会感觉非常熟悉。如果你没有接触过这些测试框架，它也只会占用你大约10分钟的时间来学习基本概念和上手。所以，让我们开始吧！

 

Note：本文偶尔会用“Google Test”来代指“Google C++ 测试框架”。

 

基本概念

 

使用Google Test时，你是从编写断言开始的，而断言是一些检查条件是否为真的语句。一个断言的结果可能是成功、非致命失败，或者致命失败。如果一个致命失败出现，他会结束当前的函数；否则，程序继续正常运行。

 

测试使用断言来验证被测代码的行为。如果一个测试崩溃或是出现一个失败的断言，那么，该测试失败；否则该测试成功。

 

一个测试案例（test case）包含了一个或多个测试。你应该将自己的测试分别归类到测试案例中，以反映被测代码的结构。当测试案例中的多个测试需要共享通用对象和子程序时，你可以把他们放到一个测试固件（test fixture）类中。

 

一个测试程序可以包含多个测试案例。

 

从编写单个的断言开始，到创建测试和测试案例，我们将会介绍怎样编写一个测试程序。

 

断言

 

Google Test中的断言是一些与函数调用相似的宏。要测试一个类或函数，我们需要对其行为做出断言。当一个断言失败时，Google Test会在屏幕上输出该代码所在的源文件及其所在的位置行号，以及错误信息。也可以在编写断言时，提供一个自定义的错误信息，这个信息在失败时会被附加在Google Test的错误信息之后。

 

断言常常成对出现，它们都测试同一个类或者函数，但对当前功能有着不同的效果。ASSERT_*版本的断言失败时会产生致命失败，并结束当前函数。EXPECT_*版本的断言产生非致命失败，而不会中止当前函数。通常更推荐使用EXPECT_*断言，因为它们运行一个测试中可以有不止一个的错误被报告出来。但如果在编写断言如果失败，就没有必要继续往下执行的测试时，你应该使用ASSERT_*断言。

 

因为失败的ASSERT_*断言会立刻从当前的函数返回，可能会跳过其后的一些的清洁代码，这样也许会导致空间泄漏。根据泄漏本身的特质，这种情况 也许值得修复，也可能不值得我们关心——所以，如果你得到断言错误的同时，还得到了一个堆检查的错误，记住上面我们所说的这一点。

 

要提供一个自定义的错误消息，只需要使用<<操作符，或一个<<操作符的序列，将其输入到框架定义的宏中。下面是一个例子：

 

 
Cpp代码  收藏代码
  1. ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";  
  2. for (int i = 0; i < x.size(); ++i) {  
  3.   EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i;  
  4. }  
 

任何能够被输出到ostream中的信息都可以被输出到一个断言宏中——特别是C字符串和string对象。如果一个宽字符串 （wchar_t*，windows上UNICODE模式TCHAR*或std::wstring）被输出到一个断言中，在打印时它会被转换成UTF-8 编码。

 

基本断言

 

下面这些断言实现了基本的true/false条件测试。

 

致命断言 非致命断言 验证条件
ASSERT_TRUE(condition); EXPECT_TRUE(condition); condition为真
ASSERT_FALSE(condition); EXPECT_FALSE(condition); condition 为假

 

记住，当它们失败时，ASSERT_*产生一个致命失败并从当前函数返回，而EXCEPT_*产生一个非致命失败，允许函数继续运行。在两种情况下，一个断言失败都意味着它所包含的测试失败。

 

有效平台：Linux、Windows、Mac。

 

二进制比较

 

本节描述了比较两个值的一些断言。

 

致命断言 非致命断言 验证条件
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

 

在出现失败事件时，Google Test会将两个值（Val1和Val2）都打印出来。在ASSERT_EQ*和EXCEPT_EQ*断言（以及我们随后介绍类似的断言）中，你应该把你希望测试的表达式放在actual（实际值）的位置上，将其期望值放在expected（期望值）的位置上，因为Google Test的测试消息为这种惯例做了一些优化。

 

参数值必须是可通过断言的比较操作符进行比较的，否则你会得到一个编译错误。参数值还必须支持<<操作符来将值输入到ostream中。所有的C++内置类型都支持这一点。

 

这些断言可以用于用户自定义的型别，但你必须重载相应的比较操作符（如==、<等）。如果定义有相应的操作符，推荐使用ASSERT_*()宏，因为它们不仅会输出比较的结果，还会输出两个比较对象。

 

参数表达式总是只被解析一次。因此，参数表达式有一定的副作用（side effect，这里应该是指编译器不同，操作符解析顺序的不确定性）也是可以接受的。但是，同其他普通C/C++函数一样，参数表达式的解析顺序是不确定的（如，一种编译器可以自由选择一种顺序来进行解析），而你的代码不应该依赖于某种特定的参数解析顺序。

 

ASSERT_EQ()对指针进行的是指针比较。即，如果被用在两个C字符串上，它会比较它们是否指向同样的内存地址，而不是它们所指向的字符串是否有相同值。所以，如果你想对两个C字符串（例如，const char*）进行值比较，请使用ASSERT_STREQ()宏，该宏会在后面介绍到。特别需要一提的是，要验证一个C字符串是否为空（NULL），使用ASSERT_STREQ(NULL, c_string)。但是要比较两个string对象时，你应该使用ASSERT_EQ。

 

本节中介绍的宏都可以处理窄字符串对象和宽字符串对象（string和wstring）。

 

有效平台：Linux、Windows、Mac。

 

字符串比较

 

该组断言用于比较两个C字符串。如果你想要比较两个string对象，相应地使用EXPECT_EQ、EXPECT_NE等断言。

 

致命断言 非致命断言 验证条件
ASSERT_STREQ(expected_str, actual_str); EXPECT_STREQ(expected_str, actual_str); 两个C字符串有相同的内容
ASSERT_STRNE(str1, str2); EXPECT_STRNE(str1, str2); 两个C字符串有不同的内容
ASSERT_STRCASEEQ(expected_str, actual_str); EXPECT_STRCASEEQ(expected_str, actual_str); 两个C字符串有相同的内容，忽略大小写
ASSERT_STRCASENE(str1, str2); EXPECT_STRCASENE(str1, str2); 两个C字符串有不同的内容，忽略大小写

 

注意断言名称中出现的“CASE”意味着大小写被忽略了。

 

*STREQ*和*STRNE*也接受宽字符串（wchar_t*）。如果两个宽字符串比较失败，它们的值会做为UTF-8窄字符串被输出。

 

一个NULL空指针和一个空字符串会被认为是不一样的。

 

有效平台：Linux、Windows、Mac。

 

参见：更多的字符串比较的技巧（如子字符串、前缀和正则表达式匹配），请参见[Advanced Guide Advanced Google Test Guide]。

 

简单的测试

 

要创建一个测试：

  1. 使用TEST（）宏来定义和命名一个测试函数，它们是一些没有返回值的普通C++函数。
  2. 在这个函数中，与你想要包含的其它任何有效C++代码一起，使用Google Test提供的各种断言来进行检查。
  3. 测试的结果由其中的断言决定；如果测试中的任意断言失败（无论是致命还是非致命），或者测试崩溃，那么整个测试就失败了。否则，测试通过。 
Cpp代码  收藏代码
  1. TEST(test_case_name, test_name) {  
  2. ... test body ...  
  3. }  
 

TEST（）的参数是从概括到特殊的。第一个参数是测试案例的名称，第二个参数是测试案例中的测试的名称。记住，一个测试案例可以包含任意数量的独立测试。一个测试的全称包括了包含它的测试案例名称，及其独立的名称。不同测试案例中的独立测试可以有相同的名称。

 

举例来说，让我们看一个简单的整数函数：

 

Cpp代码  收藏代码
  1. int Factorial(int n); // 返回n的阶乘  
 

 

这个函数的测试案例应该看起来像是：

 

Cpp代码  收藏代码
  1. // 测试0的阶乘  
  2. TEST(FactorialTest, HandlesZeroInput) {  
  3.   EXPECT_EQ(1, Factorial(0));  
  4. }  
  5. // 测试正数的阶乘  
  6. TEST(FactorialTest, HandlesPositiveInput) {  
  7.   EXPECT_EQ(1, Factorial(1));  
  8.   EXPECT_EQ(2, Factorial(2));  
  9.   EXPECT_EQ(6, Factorial(3));  
  10.   EXPECT_EQ(40320, Factorial(8));  
  11. }  
 

 

Google Test根据测试案例来分组收集测试结果，因此，逻辑相关的测试应该在同一测试案例中；换句话说，它们的TEST（）的第一个参数应该是一样的。在上面的 例子中，我们有两个测试，HandlesZeroInput和HandlesPostiveInput，它们都属于同一个测试案例 FactorialTest。

 

有效平台：Linux、Windows、Mac。

 

测试固件（Test Fixtures，又做测试夹具、测试套件）：在多个测试中使用同样的数据配置

 

当你发现自己编写了两个或多个测试来操作同样的数据，你可以采用一个测试固件。它让你可以在多个不同的测试中重用同样的对象配置。

 

要创建测试固件，只需：

  1. 创建一个类继承自testing::Test。将其中的成员声明为protected:或是public:，因为我们想要从子类中存取固件成员。
  2. 在该类中声明你计划使用的任何对象。
  3. 如果需要，编写一个默认构造函数或者SetUp()函数来为每个测试准备对象。常见错误包括将SetUp()拼写为Setup()（小写了u）——不要让它发生在你身上。
  4. 如果需要，编写一个析构函数或者TearDown()函数来释放你在SetUp()函数中申请的资源。要知道什么时候应该使用构造函数/析构函数，什么时候又应该使用SetUp()/TearDown()函数，阅读我们的FAQ。
  5. 如果需要，定义你的测试所需要共享的子程序。

当我们要使用固件时，使用TEST_F()替换掉TEST()，它允许我们存取测试固件中的对象和子程序：

 

Cpp代码  收藏代码
  1. TEST_F(test_case_name, test_name) {  
  2. ... test body ...  
  3. }  

 

与TEST()一样，第一个参数是测试案例的名称，但对TEST_F()来说，这个名称必须与测试固件类的名称一些。你可能已经猜到了：_F正是指固件。

 

不幸地是，C++宏系统并不允许我们创建一个单独的宏来处理两种类型的测试。使用错误的宏会导致编译期的错误。

 

而且，你必须在TEST_F()中使用它之前，定义好这个测试固件类。否则，你会得到编译器的报错：“virtual outside class declaration”。

对于TEST_F()中定义的每个测试，Google Test将会：

  1. 在运行时创建一个全新的测试固件
  2. 马上通过SetUp()初始化它，
  3. 运行测试
  4. 调用TearDown()来进行清理工作
  5. 删除测试固件。注意，同一测试案例中，不同的测试拥有不同的测试固件。Google Test在创建下一个测试固件前总是会对现有固件进行删除。Google Test不会对多个测试重用一个测试固件。测试对测试固件的改动并不会影响到其他测试。

例如，让我们为一个名为Queue的FIFO队列类编写测试，该类的接口如下：

 
Cpp代码  收藏代码
  1. template <typename E> // E为元素类型  
  2. class Queue {  
  3. public:  
  4.   Queue();  
  5.   void Enqueue(const E& element);  
  6.   E* Dequeue(); // 返回 NULL 如果队列为空.  
  7.   size_t size() const;  
  8.   ...  
  9. };  

 

首先，定义一个固件类。习惯上，你应该把它的名字定义为FooTest，这里的Foo是被测试的类。

 
Cpp代码  收藏代码
  1. class QueueTest : public testing::Test {  
  2. protected:  
  3.   virtual void SetUp() {  
  4.     q1_.Enqueue(1);  
  5.     q2_.Enqueue(2);  
  6.     q2_.Enqueue(3);  
  7.   }  
  8.   // virtual void TearDown() {}  
  9.   Queue<int> q0_;  
  10.   Queue<int> q1_;  
  11.   Queue<int> q2_;  
  12. };  
 

在这个案例中，我们不需要TearDown()，因为每个测试后除了析构函数外不需要进行其它的清理工作了。

 

接下来我们使用TEST_F()和这个固件来编写测试。

 

Cpp代码  收藏代码
  1. TEST_F(QueueTest, IsEmptyInitially) {  
  2.   EXPECT_EQ(0, q0_.size());  
  3. }  
  4. TEST_F(QueueTest, DequeueWorks) {  
  5.   int* n = q0_.Dequeue();  
  6.   EXPECT_EQ(NULL, n);  
  7.   
  8.   n = q1_.Dequeue();  
  9.   ASSERT_TRUE(n != NULL);  
  10.   EXPECT_EQ(1, *n);  
  11.   EXPECT_EQ(0, q1_.size());  
  12.   delete n;  
  13.   
  14.   n = q2_.Dequeue();  
  15.   ASSERT_TRUE(n != NULL);  
  16.   EXPECT_EQ(2, *n);  
  17.   EXPECT_EQ(1, q2_.size());  
  18.   delete n;  
  19. }  
 

上面这段代码既使用了ASSERT_*断言，又使用了EXPECT_*断言。经验上讲，如果你想要断言失败后，测试能够继续进行以显示更多的错误 时，你应该使用EXPECT_*断言；使用ASSERT_*如果该断言失败后继续往下执行毫无意义。例如，Dequeue测试中的第二个断言是 ASSERT_TURE(n!= NULL)，因为我们随后会n指针解引用，如果n指针为空的话，会导致一个段错误。

 

当这些测试开始时，会发生如下情况：

  1. Google Test创建一个QueueTest对象（我们把它叫做t1）。
  2. t1.SetUp()初始化t1。
  3. 第一个测试（IsEmptyInitiallly）在t1上运行。
  4. 测试完成后，t1.TearDown()进行一些清理工作。
  5. t1被析构。
  6. 以上步骤在另一个QueueTest对象上重复进行，这回会运行DequeueWorks测试。

有效平台：Linux、Windows、Mac。

 

注意：当一个测试对象被构造时，Google Test会自动地保存所有的Google Test变量标识，对象析构后进行恢复。

 

调用测试

 

TEST()和TEST_F()向Google Test隐式注册它们的测试。因此，与很多其他的C++测试框架不同，你不需要为了运行你定义的测试而将它们全部再列出来一次。

 

在定义好测试后，你可以通过RUN_ALL_TESTS()来运行它们，如果所有测试成功，该函数返回0，否则会返回1.注意RUN_ALL_TESTS()会运行你链接到的所有测试——它们可以来自不同的测试案例，甚至是来自不同的文件。

 

当被调用时，RUN_ALL_TESTS()宏会：

  1. 保存所有的Google Test标志。
  2. 为一个侧测试创建测试固件对象。
  3. 调用SetUp()初始化它。
  4. 在固件对象上运行测试。
  5. 调用TearDown()清理固件。
  6. 删除固件。
  7. 恢复所有Google Test标志的状态。
  8. 重复上诉步骤，直到所有测试完成。

此外，如果第二步时，测试固件的构造函数产生一个致命错误，继续执行3至5部显然没有必要，所以它们会被跳过。与之相似，如果第3部产生致命错误，第4部也会被跳过。

 

重要：你不能忽略掉RUN_ALL_TESTS()的返回值，否则gcc会报一个编译错误。这样设计的理由是自动化测试服务会根据测试退出返回码来 决定一个测试是否通过，而不是根据其stdout/stderr输出；因此你的main()函数必须返回RUN_ALL_TESTS()的值。

 

而且，你应该只调用RUN_ALL_TESTS()一次。多次调用该函数会与Google Test的一些高阶特性（如线程安全死亡测试thread-safe death tests）冲突，因而是不被支持的。

 

有效平台：Linux、Windows、Mac。

 

编写main()函数

 

你可以从下面这个样板开始:

 

Cpp代码  收藏代码
  1. #include "this/package/foo.h"  
  2. #include <gtest/gtest.h>  
  3. namespace {  
  4. // 测试Foo类的测试固件  
  5. class FooTest : public testing::Test {  
  6. protected:  
  7.   // You can remove any or all of the following functions if its body  
  8.   // is empty.  
  9.   FooTest() {  
  10.     // You can do set-up work for each test here.  
  11.   }  
  12.   virtual ~FooTest() {  
  13.     // You can do clean-up work that doesn't throw exceptions here.  
  14.   }  
  15.   // If the constructor and destructor are not enough for setting up  
  16.   // and cleaning up each test, you can define the following methods:  
  17.   virtual void SetUp() {  
  18.     // Code here will be called immediately after the constructor (right  
  19.     // before each test).  
  20.   }  
  21.   virtual void TearDown() {  
  22.     // Code here will be called immediately after each test (right  
  23.     // before the destructor).  
  24.   }  
  25.   // Objects declared here can be used by all tests in the test case for Foo.  
  26. };  
  27.   
  28. // Tests that the Foo::Bar() method does Abc.  
  29. TEST_F(FooTest, MethodBarDoesAbc) {  
  30.   const string input_filepath = "this/package/testdata/myinputfile.dat";  
  31.   const string output_filepath = "this/package/testdata/myoutputfile.dat";  
  32.   Foo f;  
  33.   EXPECT_EQ(0, f.Bar(input_filepath, output_filepath));  
  34. }  
  35.   
  36. // Tests that Foo does Xyz.  
  37. TEST_F(FooTest, DoesXyz) {  
  38.   // Exercises the Xyz feature of Foo.  
  39. }  
  40. }  // namespace  
  41.   
  42. int main(int argc, char **argv) {  
  43.   testing::InitGoogleTest(&argc, argv);  
  44.   return RUN_ALL_TESTS();  
  45. }  

 

testing::InitGoogleTest()函数负责解析命令行传入的Google Test标志，并删除所有它可以处理的标志。这使得用户可以通过各种不同的标志控制一个测试程序的行为。关于这一点我们会在GTestAdvanced中讲到。你必须在调用RUN_ALL_TESTS()之前调用该函数，否则就无法正确地初始化标示。

 

在Windows上InitGoogleTest()可以支持宽字符串，所以它也可以被用在以UNICODE模式编译的程序中。

 

进阶阅读

 

恭喜你！你已经学到了一些Google Test基础。你可以从编写和运行几个Google Test测试开始，再阅读一下GoogleTestSamples，或是继续研究GoogleTestAdvancedGuide，其中描述了很多更有用的Google Test特性。

 

已知局限

 

Google Test被设计为线程安全的。但是，我们还没有时间在各种平台上实现同步原语（synchronization primitives）。因此，目前从两个线程同时使用Google Test断言是不安全的。由于通常断言是在主线程中完成的，因此在大多数测试中这都不算问题。如果你愿意帮忙，你可以试着在gtest-port.h中实现必要的同步原语。

posted @ 2013-01-08 15:25  度娘818  阅读(221)  评论(0)  编辑  收藏  举报