Structuring Our Projects for Testing

C++ has some limited introspection capabilities, but cannot offer such powerful retrospection features as Java can. This might be the very reason why writing tests and unit-testing frameworks for C++ code is much harder than in other, richer environments. One implication of such an economic approach is the fact that the programmer has to be more involved in crafting testable code. We'll not only have to design our interfaces more carefully, but also answer questions about the practicalities, such as this: How do we avoid doubling the compilation and reuse artifacts between tests and production?

Compilation time might not be a significant problem for smaller projects, but as time flies, the projects grow. The need for short compilation loops does not go away. In the previous example, we appended all the sut sources to the unit-test executable apart from the main.cpp file. If we were reading closely, we would have noticed that we had some code in that file that didn't get tested (the contents of main() itself). By compiling the code twice, there's a slight chance that the produced artifacts won't be exactly the same. These things can potentially diverge over time (due to the addition of compilation flags and ...