Project structure for unit testing and coverage

[craig.scott]

Glad you’re finding the book useful. I’ll split up my reply into separate posts to make them easier to digest.

@Bert

Question 1
I am seriously questioning my directory structure. In the book I referenced above, it mentions.

Instead of running ctest from the top of the build tree, it can be run from subdirectories below it. Only those tests defined from that directory’s associated source directory and below will be known to ctest. To be able to take full advantage of this, tests should not all be collected together in one place and defined with no directory structure. It may be useful to keep tests close to the source code they are testing so that the natural directory structure of the source code can be re-used to also give structure to the tests. If the source code is ever moved around, this approach also makes it easier to move the associated tests with it.

With that said, I wonder if my root-level “tests” directory is violating this suggestion. Maybe the better approach from a CMake point of view would be to have a “test” directory for each module. For example, the ADC driver, GPIO, UART, APP_(x) would all have their own separate test directory within the module itself, i.e next to the source.

Your suspicion is correct. I would recommend keeping unit tests close to the code they are testing. In your scenario, that would mean putting unit tests with each module. For example, part of your directory structure would then look something like this:

Example_Project
|   CMakeLists.txt
|   CMakePresets.json
|   main.cpp
:
+---drivers
|   +---adc
|   |   |   CMakeLists.txt
|   |   |
|   |   +---inc
|   |   |       adc.h
|   |   |
|   |   +---src
|   |   |       adc.cpp
|   |   |
|   |   \---tests
:   :           CMakeLists.txt
:   :           test_adc.cpp

Note that the above recommendation is for unit tests. For integration tests that span across modules, putting those under a top level tests directory like you’ve done would still be appropriate.