These are just a couple of notes for some neat tips and tricks I’ve discovered over the years when using Boost.Test. They may not be all that useful to everybody else but they’re the ones I tend to forget about and then end up rediscovering. I’m using most of these with recent versions of Boost and these were tested with 1.54.
- You can nest test suites. I don’t use this feature and was surprised to discover it, but it makes a lot of sense if you’re dealing with large test suites that can be easily broken down into smaller logical chunks.
- If you arrange the tests in test suites (which you should anyway), you can run a single test suite by using
-run_test=TestSuite
. You can also run a single test inside a test suit or a nested suit by giving the appropriate path to -run_test, like so-run_test=TestSuite/TestName
- Fixtures are normal C++ structs/classes so you can derive from them to create more specialized fixtures. For example, in a set of test suite used to test a fairly large set of COM APIs, I use a single fixture to initialize COM, then derive fixtures to set up the tests for each interface. This cuts down a lot on duplicated initialization code.
- Boost.Test supports fixtures. Make lots of use of them to set up the environment for each of your tests instead of dumping a lot of the initialization code into each test case, which makes the test cases smaller, easier to read and you can follow the “let the first call in your test be the function you’re testing” mantra.
- Members of the fixtures can be used directly in your unit tests
- You can use BOOST_CHECK/BOOST_REQUIRE macros in the fixtures as well, although I would advise to make fairly minimal use of that. It does help if you are trying to test what I call “flaky” pieces of code.