Google C++ Testing Framework

商業，創業，美食，葡萄酒，閱讀，網路科技。

這是我的 FB粉專以及 IG，我比較常使用 Threads，歡迎大家追蹤互動~

I have heard this testing framework so many times, so I decided to investigate it somehow.
The official wiki link:
https://code.google.com/p/googletest/w/list
v1_6_Primer
https://code.google.com/p/googletest/wiki/V1_6_Primer
v1_6_AdvancedGuide
https://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide

Simple Test

TEST(test_case_name, test_name) 
{
  //... test body ...
}

Test Fixture

TEST_F(test_case_name, test_name) 
{
  //... test body ...
}

The above test_case_name must be your test fixture class, which must inherit from testing::Test. You can optionally override the functions: SetUp and TearDown. In a TEST_F, the flow is like:
1. the test fixture class constructs.
2. its SetUp function is called (if there is).
3. do your arrangement and assertion works.
4. the TearDown function is called (if there is).
5. the test fixture class destructs.

The above a, b, d, e are automatically done, which means you don't see it in a TEST_F. However, step c is the tester's job.

Typed Test
1. Implement a template fixture class (a template class inherits from testing::Test).
2. Use TYPED_TEST_CASE to define the data types that will run as the template argument of the template fixture class.
3. Use TYPED_TEST to start a test case. Note the 1st argument should be the template fixture class. Besides, the test case will run N times depending on how many data types you define in the above step 2.

Type-Parameterized Test
1. Implement a template fixture class (a template class inherits from testing::Test).
2. Use TYPED_TEST_CASE_P to inform the framework that you will have a test case.
3. Use TYPED_TEST_P to start a test case. Note until now the framework has no idea what data types to run in the test case.
4. An extra step: use REGISTER_TYPED_TEST_CASE_P to register the test case and all the tests under it.
5. Finally, tell the framework what data types to run in the test case by using INSTANTIATE_TYPED_TEST_CASE_P (see v1_6_AdvancedGuide for the usage).

By the test method, the same test case can have different sets of testing data types.

Value-Parameterized Test
1. Implement a fixture class (inherits from testing::TestWithParam<T>, and T must be assigned).

2. When implementing the fixture class, you can override the SetUp and TearDown functions, and use GetParam to get the test parameters (which will be set later but with the data type T in the above step 1).

3. Use TEST_P to start a test case. Note until now the framework has no idea what data values to run in the test case.

4. Tell the framework what data values to run in the test case by using INSTANTIATE_TEST_CASE_P (see v1_6_AdvancedGuide for the usage). The 3rd argument can be:
Range
Values
ValuesIn
Bool
Combine

,which generate different sets of test parameters. The same as Type-Parameterized Test, this test method instantiates a test case AFTER the fixture class.

Define your custom event listeners
1. Implement an event listener class (inherits from testing::TestEventListener or testing::EmptyTestEventListener.)
2. Register your event listener class to the framework, like: (from Google provided sample sample9_unittest.cc)

TestEventListeners& listeners = unit_test.listeners();
delete listeners.Release(listeners.default_result_printer());
listeners.Append(new TersePrinter);

Then you can have your custom event listener when, say, a test starts/ends, assertion fails/succeeds, etc.

Note that sample10_unittest.cc demonstrates a nice way for memory leak check, where each class in your system should keep the creating count in such class, and the client side also keeps a count. Also note this is just one way to prevent from memory leak.