We have an extensive C++ code base for our data acquisition back-end.  You could euphemistically call it “organic”. We’re trying to improve the code base by refactoring.  If you deal with legacy C++ code, you really need to get Michael Feather‘s book Working Effectively with Legacy code.  The man is a genius!

Since this code base had no unit tests, and we don’t like refactoring without some tests, we decided to investigate what was available in the windows C++ world.  We decided to use CppUnitLite simply because it was easy to integrate with our vintage tools.  We soon ran into a minor stumbling block…
Our back-end consists of multiple DLLs, mostly involved with acquiring data from various devices (e.g. a plug-in type of architecture). We wanted to run the Unit Tests on objects internal to the DLLs; those objects are not exposed to the DLL clients.  It is simply not practical (or advisable) to expose those objects.

The solution:  put the unit tests inside the dll, and expose a single function to perform the actual test execution.  You then have a simple external driver program load the dll and call that function.  No need to expose your guts.

Clearly, you want to be careful to not have the unit tests in the version of the DLL you ship out.  Simply have a #define controlling wether the tests are compiled in or not.

Just a neat little technique for those running into this problem.