How to keep settings for C++ Unit Test modules in sync with the production code modules?

Question

• 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:

• Klass1.h/cpp
• Klass2.h/cpp
• 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.}

Answer 1

Use CMake or another sane (meta-)build system which takes care of the build settings automatically, or allows you to share them across projects.

Answer 2

As a UNIX guy (primarily) the first thing I'd do is write a script to manage these things for me. Never do anything even slightly complex manually if you can easily script it.

The script could accept a file to add or remove from the project, and update all the relevant projects. The script could even accept a project name and infer its test project, if you're into using conventions.

The bottom line is this: if you know how to do it manually, and it's tedious -- script it.

Answer 3

This is how we ended up setting our projects:

We added new "Test debug"/"Test release' configurations for every existing project that we have, you can add only to the ones which have unit tests in it.

For .exe/.dll projects we disable the original main.cpp from compiling and replaced it with the one that instantiates the test framework (e.g. gtest) and runs all the tests, the tests are in separate .cpp files which are also excluded from compilation in regular configurations (Release/Debug) and enabled only in Test configurations.

For .lib projects we also have new "Test debug"/"Test release" configurations and there we convert the static library to be an .exe file and provide a main.cpp which instantiates the testing framework and runs the tests and tests themselves. Test related files are excluded from compilation on Release/Debug configurations.