Google C++ Testing Framework

1. Google C++ Testing Framework Test Fixtures: Using the Same Data Configuration for Multiple Tests

2. Understanding Test Fixtures • It is typical to do some custom initialization work before executing a unit test. • For example, if you are trying to measure the time/memory footprint of a test, you need to put some test-specific code in place to measure those values. • This is where fixtures come in—they help you set up such custom testing needs

3. Vector Demo

4. Steps for create a fixture • Derive a class from ::testing::Test . Start its body with protected: or public: as we'll want to access fixture members from sub-classes. • Inside the class, declare any objects you plan to use. • 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. • 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. • If needed, define subroutines for your tests to share.

5. Invoking the tests • TEST() and TEST_F() implicitly register their tests with Google Test. • you don't have to re-list all your defined tests in order to run them. • After defining your tests, you can run them with RUN_ALL_TESTS() , • returns 0 if all the tests are successful • or 1 otherwise. • Note: RUN_ALL_TESTS() runs all tests in your link unit -- they can be from different test cases, or even different source files.

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