Seeking suggestions for Unit Testing C++ app spread over several dlls

Question

New to unit testing and have an app that is spread out over several dlls. What are some suggestions for unit testing the app? If I put the unit tests in their own project, i can only test the published interface for each dll. Is that what most people do? Or should I put the unit tests in with the code in the dlls and test there? What would be the best way to coordinate all the tests at that point?

Most of the examples I've seen for using the various frameworks don't really address this and I've search elsewhere but haven't found much information.

Thanks.

Update:

I guess to clarify a bit I have class A and class B in a dll. Class B is used by Class A, but only Class A is exposed. I'm wanting to get unit tests in place before refactoring this existing code. So the question is should I put unit tests in with the dll code to test class A and class B directly and/or have the unit tests in a separate project and test class A and class B through the exposed class A?

Answer 1

My home-rolled approach to this is to build two different targets:

• the DLL itself
• a test executable

The code base is the same except for main.cpp which will contain a DLL main for the DLL and a standard C/C++ int main() for the test executable. All the unit tests are in-line with the actual code, controlled by a preprocessor #define:

#ifdef TESTING
tests here    
#endif

The main() for the executable calls all the tests via a registration framework.

Most of the time I work with the executable version with TESTING defined. When I want to build the DLL, I switch targets and undefine TESTING.

Answer 2

If I put the unit tests in their own project, i can only test the published interface for each dll.

As opposed to features in the DLL that client code cannot access?

If code doesn't contribute to the functions the DLL exposes, then delete it from the code base. If it does, then you can write a test that exercises that code path.

Answer 3

In general, thoroughly testing the public interface of a DLL should be sufficient and, as Pete indicated, should indeed exercise all code paths.

Regarding Neils' answer, choosing a test framework that does not require you to build EXEs but rather directly operates on DLLs could further simplify matters. Being the author of cfix, I'd naturally recommend giving cfix a try: http://www.cfix-testing.org/

Answer 4

Unit testing in C++ means rather class testing. DLL testing would be rather integration testing. Both are necessary, but it's better to test things at as low level as possible. Take a look on v-model: http://en.wikipedia.org/wiki/V-Model_(software_development).

Answer 5

I use boost.test to test my dlls and executables. I create a seperate unit test project/executable for each dll and exe to test. Because I test the internals of the dll I do not link them with the test project, but include the source I want to test directly in the project. Finally the automated build runs all the unit test projects.

We use CMake to build our projects and this has a nice component CTest that bundles up all our tests for us and runs them as a group.