Unit testing non-exported classes in a DLL

Question

We develop a C++ application using Visual Studio 2008 and unit test using Boost.Test. At the moment, we have a separate solution which contains our unit tests.

Many of our projects in the core solution produce DLL's. We're limited in test coverage because we cannot test non-exported classes.

I have two ideas on how these could be tested:

1. Export everything
2. Put the tests inside the DLL (same project and solution) and use Boost.Test's external runner

I'm not entirely sure what the drawbacks would be. Number 1 above breaks module level encapsulation, and number 2 could result in a much larger DLL, unless it's possible to only include the test code in certain configurations.

So, are there any severe drawbacks to the above methods, or can you think of other solutions?

Answer 1

Expanding on Tom Quarendon's answer to this question, I have used a slight variant of Simon Steele's response:

• Create a test project (using whatever test framework you like, I use CppUnit).
• In your test_case.cpp, #include <header/in/source/project.h>.
• In the test project properties:
  • In Linker->General, add the source project's $(IntDir) to the Additional Library Directories.
  • In Linker->Input, add the .obj files to the Additional Dependencies.
• Add the dependency from the test project to the source project in Project->Project Dependencies.

Again, the only maintenance overhead is the standard one for unit tests - to create the dependency on the unit(s) you want to test.

Answer 2

The solution I use for this is to build the same non-exported code into my tests DLL as well. This does increase build time and means adding everything to both projects, but saves exporting everything or putting the tests in the main product code.

Another posibility would be to compile the non-exported code into a lib which is used by both the DLL with exports, and the unit test project.