Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
  • 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.

share|improve this question

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

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.