I’m just getting started with TDD and am curious as to what approaches others take to run their tests. For reference, I am using the google testing framework, but I believe the question is applicable to most other testing frameworks and to languages other than C/C++.
My general approach so far has been to do one of three things:
-
Write the majority of the application in a static library, then create two executables. One executable is the application itself, while the other is the test runner with all of the tests. Both link to the static library.
-
Embed the testing code directly into the application itself, and enable or disable the testing code using compiler flags. This is probably the best approach I’ve used so far, but clutters up the code a bit.
-
Embed the testing code directly into the application itself, and, given certain command-line switches either run the application itself or run the tests embedded in the application.
None of these solutions are particularly elegant…
How do you do it?
I tend to favour static libs over dlls so most of my C++ code ends up in static libs anyway and, as you’ve found, they’re as easy to test as dlls.
For code that builds into an exe I either have a separate test project which simply includes the source files that are under test and that are usually built into the exe OR I build a new static lib that contains most of the exe and test that in the same way that I test all of my other static libs. I find that I usually take the ‘most code in a library’ approach with new projects and the ‘pull the source files from the exe project into the test project’ approach when I’m retro fitting tests to existing applications.
I don’t like your options 2 and 3 at all. Managing the build configurations for 2 is probably harder than having a separate test project that simply pulls in the sources it needs and including all of the tests into the exe as you suggest in 3 is just wrong 😉