- Note: I'm coming from a Windows / Visual-C++ background.
- Note: I have already read Michael Feathers' Working Effectively with Legacy Code.
- Note: Broad question, asking for narrow answers, i.e. while I don't want to narrow this question down to a specific compiler/platform/make system, useful answers will likely only contain one combination.
The C++ development model
Even ideally, you have your, well organized, source files:
- CustomAlgorithms.h (header only)
- main.cpp (may not be needed for a dyn/static lib module)
Then, your application consists of n modules (even if they are just static libraries all linked together to an executable module in the end.
To get from the source to the binary module(s), you need project files / make files / whatever. These files "tell" the compiler (and the linker) how to generate the binary modules from your sourcecode.
Adding in Unit Tests
Regardless of which Testing Framework you use and regardless of where you actually put your test code, you need to produce different/additional binary modules for your test code than for your production code. (At least for any executable or dynamic library, static libs should be a tad easier.)
If you need to produce different binary modules for your test code, then you need to maintain a separate/additional set of (compiler) settings for this test code.
With Visual Studio you can try to minimize the amount of work by using vsprops files, but you still are left with a separate project file for your tests and your production modules. This can become problematic to maintain.
With a make system, I'm not sure how this is done, but I explicitly want this question to encompass both, as techniques from one may translate into the other.
So, TL;DR, how do you prevent yourself from having to manually edit two different "project files" (one for test, one for production), every time you add or change something in the production settings.(*)
(*) You might think you don't change things that often, but think of a real world scale project with dozens (hundreds) of modules and dozens of developers. Each tiny amount of manual work you save for the test scaffolding will multiply.