Unit testing non-exported classes in a DLL

Jon picture Jon · Mar 31, 2011 · Viewed 7.9k times · Source

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

Rai picture Rai · Jun 17, 2014

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.