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.cppfor 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
greetinglibrary 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)
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).
A suite of unit tests is just a project depending on the tested code.
Given a project that reaches a certain, not-really-that-big size, the need arises to arrange the code on a number of separate modules (a.k.a. libraries). It seems to me the most straightforward approach to have a testing project for each of those modules, and so I do in practice. In this way, changes in the implementation of a class require the affected module to be rebuild, and no more; the related test project is only needed to be linked again, and then rerun.
It’s possible for a test suite to grow in excess, and this fact probably hints to the very same problem in its corresponding module. If that’s the case, further subdivision shows necessary.
Some testing frameworks allow you to organise tests into categories, so use this and then set the main tests to be run on every commit, and all to be run on a nightly build that builds and tests everything.
Some others have you create unit test projects – create 2 sets, one with a minimal set of tests included.
Boost::Test allows you to run test suites by name.
So it all depends which test framework you use, but my answer is still basically: run some regularly, the full suite less regularly.
2