I recently gave a demo of GoogleTest at Kjeller Software Community / Oslo C++ Users Group. These are the notes from my demo. My apologies to those who did not attend, these might not make much sense unless you saw the demo.
Installation
See my post about installation and setup of GoogleTest in your project.
Test types
TEST(TestCaseName, TestName)
A single test TestName
belonging to the TestCaseName
test case. The TEST
macro converts this into class TestCaseName_TestName
TEST_F(TestFixtureName, TestName)
A single test TestName
belonging to the TestFixtureName
test case, which uses a fixture. The TEST_F
macro converts this into class TestFixtureName_TestName : public TestFixtureName
. You need to implement the TestFixtureName : public ::testing::Test
class also.
TEST_P(TestFixtureName, TestName)
A single parametrized test TestName
belonging to the TestFixtureName
test case, which uses a fixture with a parametrized interface. You need to implement the TestFixtureName : public ::testing::WithParamInterface
class also. Use GetParam()
to get the parameter, and INSTANTIATE_TEST_CASE_P
to instantiate tests.
Finally remember that you can use SetUp()
and TearDown()
, but might just as well use the plain constructor and destructor. A reason to use TearDown()
instead of the destructor is if it might throw an exception (which destructors should not do).
Assertions
Here are some examples of assertions:
ASSERT_TRUE
ASSERT_FALSE
ASSERT_EQ
ASSERT_DOUBLE_EQ
ASSERT_LT
ASSERT_THROW
You can also write your own assertion functions:
AssertionResult predicateFunction(...)
Or just write a void function that does all the asserts internally:
void assertWhatever()
Some final tips
Use one test project per production project, for instance NoFlyListTest
for NoFlyList
. This makes it easy to find the tests for a project. If the rest of your code is decoupled, it might also speed up linking a lot, since you only need to link the test project, and not your entire solution. This especially helps if you are doing TDD, in which you will typically compile and link several times a minute.
Write short tests, and only test one thing per test. This will make it easy to figure out what went wrong when tests break in the future.
Write tests before you implement the code that passes them. This will verify that the test didn’t pass just by accident. It will also let you see how the failing test looks like, so you can make sure it is self-explanatory enough that someone will understand what went wrong when it breaks.
Don’t be a terrorist, you’ll end up in a bad place.
Source Code
If you want to have a look at the code from my Kjeller Software Community demo, it is available on GitHub.
If you enjoyed this post, you can subscribe to my blog, or follow me on Twitter.