How to structure cppunit tests in non-trivial software systems so that they can be easily executed selectively during code-compile-test cycle and at the same time are easy to execute as a whole by your continuous integration system.
While unit testing in Java is dominated by JUnit, C++ developers can choose between a variety of frameworks. See here for a comprehensive list. Here you can find a nice comparison of the biggest players in the game.
Being probably one of the oldest frameworks CppUnit sure has some usability issues but is still widely used. It is criticised mostly because you have to do a lot of boilerplate typing to add new tests. In the following I will not repeat how tests can be written in CppUnit as this is described already exhaustively (e.g. here or here). Instead I will concentrate on the task of how to structure CppUnit tests in bigger projects. “Bigger” in this case means at least a few architectually independent parts which are compiled independently, i.e. into different libraries.
Having independently compiled parts in your project means that you want to compile their unit tests independently, too. The goal is then to structure the tests so that they can easily be executed selectively during development time by the programmer and at the same time are easy to execute as a whole during CI time (CI meaning Continuous Integration, of course).
As C++ has no reflection or other meta programming elements like the Java Annotations, things like automatic test discovery and how to add new tests become a whole topic of its own. See the CppUnit cookbook for how to do that with CppUnit . In my projects I only use the TestFactoryRegistry approach because it provides the most automatics in this regard.
Let’s begin with a simplest setup, the Link-Time Trap (see example source code): Test runner and result reporter are setup in the “main” function that is compiled into an executable. The actual unit tests are compiled in separate libraries and are all linked to the executable that contains the main function. While this solution works well for small projects it does not scale. This is simply because every time you change something during the code-compile-test cycle the unit test executable has to be relinked, which can take a considerable amount of time the bigger the project gets. You fall into the Link Time Trap!
The solution I use in many projects is as follows: Like in the simple approach, there is one test main function which is compiled into a test executable. All unit tests are compiled into libraries according to their place in the system architecture. To avoid the Link-Time-Trap, they are not linked to the test executable but instead are automatically discovered and loaded during test execution.
1. Automatic Discovery
Applying a little convention-over-configuration all testing libraries end with the suffix “_tests.so”. The testing main function can then simply walk over the directory tree of the project and find all shared libraries that contain unit test classes.
2. Loading
If a “.._test.so” library has been found, it simply gets loaded using dlopen (under Unix/Linux). When the library is loaded the unit tests are automatically registered with the TestFactoryRegistry.
3. Execution
After all unit test libraries has been found and loaded text execution is the same as in the simple approach above.
Here my enhanced testmain.cpp (see example source code).
#include ...
using namespace boost::filesystem;
using namespace std;
void loadPlugins(const std::string& rootPath)
{
directory_iterator end_itr;
for (directory_iterator itr(rootPath); itr != end_itr; ++itr) {
if (is_directory(*itr)) {
string leaf = (*itr).leaf();
if (leaf[0] != '.') {
loadPlugins((*itr).string());
}
continue;
}
const string fileName = (*itr).string();
if (fileName.find("_tests.so") == string::npos) {
continue;
}
void * handle =
dlopen (fileName.c_str(), RTLD_NOW | RTLD_GLOBAL);
cout << "Opening : " << fileName.c_str() << endl;
if (!handle) {
cout << "Error: " << dlerror() << endl;
exit (1);
}
}
}
int main ( int argc, char ** argv ) {
string rootPath = "./";
if (argc > 1) {
rootPath = static_cast<const char*>(argv[1]);
}
cout << "Loading all test libs under " << rootPath << endl;
string runArg = std::string ( "All Tests" );
// get registry
CppUnit::TestFactoryRegistry& registry =
CppUnit::TestFactoryRegistry::getRegistry();
loadPlugins(rootPath);
// Create the event manager and test controller
CppUnit::TestResult controller;
// Add a listener that collects test result
CppUnit::TestResultCollector result;
controller.addListener ( &result );
CppUnit::TextUi::TestRunner *runner =
new CppUnit::TextUi::TestRunner;
std::ofstream xmlout ( "testresultout.xml" );
CppUnit::XmlOutputter xmlOutputter ( &result, xmlout );
CppUnit::TextOutputter consoleOutputter ( &result, std::cout );
runner->addTest ( registry.makeTest() );
runner->run ( controller, runArg.c_str() );
xmlOutputter.write();
consoleOutputter.write();
return result.wasSuccessful() ? 0 : 1;
}
As you can see the loadPlugins function uses the Boost.Filesystem library to walk over the directory tree.
It also takes a rootPath argument which you can give as parameter when you call the test main executable. This solves our goal stated above. When you want to execute unit tests selectively during development you can give the path of the corresponding testing library as parameter. Like so:
./testmain path/to/specific/testing/library
In your CI environment on the other hand you can execute all tests at once by giving the root path of the project, or the path where all testing libraries have been installed to.
./testmain project/root
Schneide Blog 