Where do I place the Unit Testing source and expose the internal components?

Question

I am taking over a project that exposes components via ATL.

I see two major areas for the unit test to cover with this setup:

• Testing the internal components (may or may not be exposed via COM)
• Testing the external exposed components (aka testing the exposed interface)

Currently the project has all of its internal components unit tests inside of the solution. They are enabled by a preprocessor flag that compiles it in and executes when you run.

From the research I have been doing, it appears that the "norm" is to place the unit testing in a different sub project and to have the main solution supply hooks for the unit tests to access internal components. With this setup, the unit testing solution would set a dependency to the solution being tested. Is this truly the "norm", or are there a lot of people out there that place their unit testing framework inside of the solution that is being tested (aka unit test is not a sub project but rather loose cpps that are #ifdef'd out if the preprocessor flag is not supplied)?

It appears that the unit testing framework currently in use is cppunit and I was thinking of switching it over to gtest and trying to move everything into a different sub project but I want to make sure the effort will be worth it in the long run.

One way I thought of was to __declspec the classes to be tested and they are only exposed when the preprocessor define is specified. Then the separate unit test sub project would enable that preprocessor to tell the main solution to expose the inners. I am just not sure if this is the best route.

So my questions are:

1. Is the norm to place unit tests in a separate (sub)project and expose the components from the source that will be tested (either via hooks, exposing the class definition, etc)?
2. What is the best way to expose the internal components from a COM DLL?
3. Would a preprocessor flag that enables __declspec for the internal components to be tested a bad idea? Has anyone else done this with their unit tests where the item being tested is not normally exposed during normal operation?

Thanks for the comments!

Answer 1

Someone on another team said that their team placed all of the unit tests in separate projects and were able to expose the internals via static libs. This makes a lot of sense to me in that it helps with modularity and provides alot of other benefits. So each major coupling of code would be a static lib (without going too overboard ;) ) and for each static lib, you would have a separate unit test solution. Then your main DLL becomes a thin wrapper that exposes the necessary items.

So the solution would look like:

MainSolution

• ProjCommonLib
• ProjExportsLib
• ProjImportsLib
• ProjOtherStuffLib
• COMDLL-Proj
• UnitTestsFolder
  • ProjCommonLibTests
  • ProjExportsLibTests
  • ProjImportsLibTests
  • ProjOtherStuffLibTests
  • COMDLL-ProjTests

This type of setup allows the unit tests to set dependencies on the static lib and have full access to the internals without ever having to deal with __declspec. This seems a lot cleaner because the DLL doesn't have any performance hit with the modularity because the other libraries are just that, static libraries.

I am placing this as an "answer" to see if it gets any up votes (aka, "this answer is a good approach and is what I do as well"). If this is a bad solution please post your answers.