gtest 学习一

学习原因：

一直听说却从未动手用过的gtest，今天终于开始学习了。

我总是觉得学习一样东西需要某种驱动力，最近组里在组织加强developer写code的自我测试能力，提倡大家使用一下，所以找到驱动力之后准备认真研究一下，提升自己！

 

学习路程：

在百度，谷歌搜索了一番发现了一些博客，看这比较舒服的大部分都是对gtest的手册进行翻译得来，但是又觉得少点东西，最后痛下决心，准备用自己支离破碎的English去攻克gtest手册。

 

学习记录一：入门

选择gtest的原因主要有五点：

1. Tests should be independent and repeatable. It's a pain to debug a test that succeeds or fails as a result of other tests. Google C++ Testing Framework isolates the tests by running each of them on a different object. When a test fails, Google C++ Testing Framework allows you to run it in isolation for quick debugging.
2. Tests should be well organized and reflect the structure of the tested code. Google C++ Testing Framework groups related tests into test cases that can share data and subroutines. This common pattern is easy to recognize and makes tests easy to maintain. Such consistency is especially helpful when people switch projects and start to work on a new code base.
3. Tests should be portable and reusable. The open-source community has a lot of code that is platform-neutral, its tests should also be platform-neutral. Google C++ Testing Framework works on different OSes, with different compilers (gcc, MSVC, and others), with or without exceptions, so Google C++ Testing Framework tests can easily work with a variety of configurations. (Note that the current release only contains build scripts for Linux - we are actively working on scripts for other platforms.)
4. When tests fail, they should provide as much information about the problem as possible. Google C++ Testing Framework doesn't stop at the first test failure. Instead, it only stops the current test and continues with the next. You can also set up tests that report non-fatal failures after which the current test continues. Thus, you can detect and fix multiple bugs in a single run-edit-compile cycle.
5. The testing framework should liberate test writers from housekeeping chores and let them focus on the test content. Google C++ Testing Framework automatically keeps track of all tests defined, and doesn't require the user to enumerate them in order to run them.
6. Tests should be fast. With Google C++ Testing Framework, you can reuse shared resources across tests and pay for the set-up/tear-down only once, without making tests depend on each other.

 

介绍了两种断言，ASSERT EXPECT

Fatal assertion	Nonfatal assertion	Verifies
ASSERT_TRUE(condition);	EXPECT_TRUE(condition);	condition is true
ASSERT_FALSE(condition);	EXPECT_FALSE(condition);	condition is false

 

Fatal assertion	Nonfatal assertion	Verifies
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

 

Fatal assertion	Nonfatal assertion	Verifies
ASSERT_STREQ(expected_str, actual_str);	EXPECT_STREQ(expected_str, actual_str);	the two C strings have the same content
ASSERT_STRNE(str1, str2);	EXPECT_STRNE(str1, str2);	the two C strings have different content
ASSERT_STRCASEEQ(expected_str, actual_str);	EXPECT_STRCASEEQ(expected_str, actual_str);	the two C strings have the same content, ignoring case
ASSERT_STRCASENE(str1, str2);	EXPECT_STRCASENE(str1, str2);	the two C strings have different content, ignoring case

 

并通过两个简单的例子使我了解了基本的gtest概念，以及gtest主要的设计理念，虽然还不是特别清楚。

gtest测试有简单测试和复合测试，简单的测试比较好理解，用gtest的TEST()宏进行测试。

1. Use the TEST() macro to define and name a test function, These are ordinary C++ functions that don't return a value.
2. In this function, along with any valid C++ statements you want to include, use the various Google Test assertions to check values.
3. The test's result is determined by the assertions; if any assertion in the test fails (either fatally or non-fatally), or if the test crashes, the entire test fails. Otherwise, it succeeds.

对于复杂的测试可能就要先建立一个基于::testing::Test 的累，然后用TEST_F()宏来进行相应的测试。

To create a fixture, just:

1. Derive a class from ::testing::Test . Start its body with protected: or public: as we'll want to access fixture members from sub-classes.
2. Inside the class, declare any objects you plan to use.
3. If necessary, write a default constructor or SetUp() function to prepare the objects for each test. A common mistake is to spell SetUp() asSetup() with a small u - don't let that happen to you.
4. If necessary, write a destructor or TearDown() function to release any resources you allocated in SetUp() . To learn when you should use the constructor/destructor and when you should use SetUp()/TearDown(), read this FAQ entry.
5. If needed, define subroutines for your tests to share.

For each test defined with TEST_F(), Google Test will:

1. Create a fresh test fixture at runtime
2. Immediately initialize it via SetUp() ,
3. Run the test
4. Clean up by calling TearDown()
5. Delete the test fixture. Note that different tests in the same test case have different test fixture objects, and Google Test always deletes a test fixture before it creates the next one. Google Test does not reuse the same test fixture for multiple tests. Any changes one test makes to the fixture do not affect other tests.

对于gtest的入口函数是RUN_ALL_TESTS()

which returns 0 if all the tests are successful, or 1 otherwise.

 

When invoked, the RUN_ALL_TESTS() macro:

1. Saves the state of all Google Test flags.
2. Creates a test fixture object for the first test.
3. Initializes it via SetUp().
4. Runs the test on the fixture object.
5. Cleans up the fixture via TearDown().
6. Deletes the fixture.
7. Restores the state of all Google Test flags.
8. Repeats the above steps for the next test, until all tests have run

例子：

int main(int argc,char**argv){
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

 The ::testing::InitGoogleTest() function parses the command line for Google Test flags, and removes all recognized flags. This allows the user to control a test program's behavior via various flags, which we'll cover in AdvancedGuide.

 

Known Limitations

Google Test is designed to be thread-safe. The implementation is thread-safe on systems where the pthreads library is available. It is currentlyunsafe to use Google Test assertions from two threads concurrently on other systems (e.g. Windows).  In most tests this is not an issue as usually the assertions are done in the main thread.