A natural side-effect of shifting to a dynamically-linked library for unit testing (issues #6) is that test coverage it now broken. This is because the library's *.cpp (and *_p.h) files are not compiled with -fprofile-arcs -ftest-coverage, so profiling data is not generated for them.
There's no easy way around this. We could generate additional dynamic libs with coverage enabled, but that's a lot of extra compilation, and reduces the accuracy of the unit tests (ie no longer testing the release binary).
Lately I've been pondering splitting, or rather compiling in two different modes, the unit test application - one version that tests just the public API, and could, theoretically be shipped without ABI compatibility concerns, and the other that test both public and private functions for extensive (near-100%) test coverage. Of course, the former would yield very low reported test coverage, whereas the latter would have better test coverage, but strict ABI incompatibility.
Of course, I'd use the same unit test code base for both versions - just #def out the private stuff for the public version.
If I was to split the unit test app as described above, then it would make perfect sense for the public version to be testing against the public binary release lib (and public headers only), while the internal version could link to the source code directly (maintaining the current private header access too).
Makes sense.
I'd kind of want to switch to CMake for that level of versatility though (which I've wanted to do for a little while now) :grey_question:
A natural side-effect of shifting to a dynamically-linked library for unit testing (issues #6) is that test coverage it now broken. This is because the library's
*.cpp(and*_p.h) files are not compiled with-fprofile-arcs -ftest-coverage, so profiling data is not generated for them.There's no easy way around this. We could generate additional dynamic libs with coverage enabled, but that's a lot of extra compilation, and reduces the accuracy of the unit tests (ie no longer testing the release binary).
Lately I've been pondering splitting, or rather compiling in two different modes, the unit test application - one version that tests just the public API, and could, theoretically be shipped without ABI compatibility concerns, and the other that test both public and private functions for extensive (near-100%) test coverage. Of course, the former would yield very low reported test coverage, whereas the latter would have better test coverage, but strict ABI incompatibility.
Of course, I'd use the same unit test code base for both versions - just
#defout the private stuff for the public version.If I was to split the unit test app as described above, then it would make perfect sense for the public version to be testing against the public binary release lib (and public headers only), while the internal version could link to the source code directly (maintaining the current private header access too).
Makes sense.
I'd kind of want to switch to CMake for that level of versatility though (which I've wanted to do for a little while now) :grey_question: