Reducing Unit Testing Build Time in C++ Projects

ccontinuous integrationproject-structureunit testing

I want to organize tests for a project large enough that build time matters (especially for the CI server).

Say I have this code that I would like to test :

//foo/greet.cpp
#include <stdio.h>
#include "foo/greet.h"
int greet() { return printf("Hello, World!\n"); }

And I have this main program that is boilerplate that I will not test.

//main.cpp
#include "foo/greet.h"
int main() { return greet(); }

I will use this code to generate a unittest program

//testgreet.cpp
#include <some_test_framework.h>
SOME_TEST_FRAMEWORK("Testing greet")
    SOME_TEST_FRAMEWORK_ASSERT(greet() > 0)
SOME_TEST_FRAMEWORK_END()

I thought of the following

  • Skipping the build of greet.cpp for the unittest target, and linking with the objects
  • Create a separate project structure for the tests, but share the output folder
  • Pile everything in one place, maybe with a new folder named test
  • Make a greeting library and link both main and unittests targets to it

How can I organize my project so that I can build greet.cpp only once, yet reduce confusion caused by having two targets that share a lot of code ?

This question is related, but not duplicate (IMHO).

(+I tried making my question generic, reusable and future proof. If you think that this is too opinion based, vote to close and I will not repost)

Best Answer

Your goal is simply to avoid compiling greet.cpp twice (once for the application and once for the tests). Correct?

Like you said, there are lots of ways of doing this. It's really a question of what build system you're using, how your code is organized, and how you want to organize your code.

Use a library

This is your last suggestion: Make a greeting library and link both main and unittests targets to it.

This is the cleanest solution:

  • It makes it obvious what you're doing and it should work well with any build system or IDE out there.
  • Having the application and test suite share the same library ensures that you're testing production-ready code (instead of, for example, accidentally using different compiler options for application versus test suite and failing to catch problems).
  • Putting your unit testable code in a library can help encourage good design (by keeping you from slipping dependencies on UI code or other non-unit-testable code into your library).

On the other hand, it may be more hassle to set up initially, or your project design may make it hard to cleanly split into libraries.

Share the object files

Your first three suggestions are variations on this. Some build systems make this easy. For example, the following Makefile would work:

%.o: %.cpp
  $(CXX) -c $<
main_program: greet.o main.o
  $(CXX) -o $@ $+
unit_tests: greet.o testgreet.o
  $(CXX) -o $@ $+

If you're using something like Make, this should be very easy to set up and get going. (Simply for the sake of organizing your source files, you may want to put the test sources in a separate directory, as you mentioned.)

Other build systems make this harder. For example, using IDE-managed project files and configuring the two IDE projects to share an output directory, so they happen to see each other's output, should work, but it's a bit hackish, and it can invite problems if one project's settings diverge at all from the other (since a project build may think that an object file is suitable for its own use, even if it was built using incompatible settings by the other project).

Related Topic