I'm setting up a bunch of unit tests using CppUnit but am having the problem that none of the tests are being run. The project is divided up into several small libraries and I planned on dividing the unit test classes up the same way and then linking them all into a single test program. The problem is, then the test classes are in their own libraries, they don't get linked into the main test program unless I explicitly call them, i.e. I have to put in
runner.addTest( TestClass::suite() );
individually for each test class and can't use the TestFactoryRegistry's makeTests() method to get the list of tests. If I just compile them all together in the top directory the makeTests() method works fine but I don't want to have all the test classes in one location if I can help it.
The CppUnit documentation gives the following little hint
Linking problem when using Helper macros ?
When you create a project and write its unit test suites, the work is made easier through the use of the so-called helper macros : CPPUNIT_TEST_SUITE_NAMED_REGISTRATION, CPPUNIT_REGISTRY_ADD and CPPUNIT_REGISTRY_ADD_TO_DEFAULT. The problem is that if you use those macros in the source code file of a TestFixture class (say MyTest as an example), and if you use a line like this one
runner.addTest( CppUnit::TestFactoryRegistry::getRegistry().makeTest()
);
in your main() function in file main.cpp, there will have no test run at all !
The reason is simply that the link stage, one of the step of the build process, do not insert the object files (.obj or .o files) in the final executable if there is no undefined symbol in your main.cpp.
That way, the object code which contains the AutoRegister static variables instantiation is not part of the final executable and is not able to insert oneself into the runner in the main() function.
You have to create an undefined symbol in main.cpp so that the mytest.o file is integrated with main.o into the final executable.
Trick committed by Michel Nolard
but doesn't say how to make this work and I'm just dense enough not to be able to figure it out myself or find an example on-line.
Now I could just make a separate executable test for each library, and in the end I may go that way, but I wanted to try to get this working first so I just had one single test program to run to test the whole thing. Any ideas/examples of how to get this to work?
By adding an undefined symbol to main, he just means create any random external symbol to force the linker into searching your external libraries that contain the test code.
For example, assuming two test libraries fred and barney, in fredTestLib.cpp you'd just add this line:
int fredDummyInt = 0; // declare a unique symbol for the linker to resolve
and in barneyTestLib.cpp, you'd add a similar line:
int barneyDummyInt = 0; // a different unique symbol for the linker to resolve
You could compile each library separately in different steps. In the main test program, you then force the linker to resolve them. So add these lines to main.cpp:
extern int fredDummyInt;
extern int barneyDummyInt;
...
main () {
...
fredDummyInt++; // give the linker some symbols to resolve
barneyDummyInt++;
...
The idea (according to what the author of the trick above is saying) is that because the linker is already searching fredTest.lib for fredDummyInt, it will also find and resolve your automatically registered tests.
Note: I have not tried this to see if it works! I'm just answering your question about externals.
Another approach to consider would be to create your tests in DLLs, and use LoadLibrary() to explicitly bring them in to run. For overkill, if you use the MfcUi::TestRunner, you could probably build a little drop-down GUI thing that lets you pick the library to load, loads it, then displays the tests to run in that library, then runs them.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With