Unit testing with multiple libraries in a larger build tree
I have some problems with coming up with a sufficient solution to unit test individual libraries in a larger build tree. I've got 4 different solutions where all have their drawback which I would very much like to avoid
- Linking a lib against a test executable, where the lib has its given public and private headers. This only allows me to test the public interface with no possibility of unit testing/TDD the internal features.
- Using generator expressions such as $<BUILD_INTERFACE:"path/to/internal/headers"> but this only works when the library is the only one in the build tree. If there are multiple libraries and they link against each other (non-cyclic of course) they will have all the internal headers accessible to each other which is not acceptable.
- Using variables per project to set include folders and sources and then setting them on the library and test targets. But this comes with the drawbacks of actually using variables and not adding them directly on to the target.
- Creating a test executable and a clone macro/function that copies the properties SOURCES, INTERFACE_SOURCES, LINK_LIBRARIES, INTERFACE_LINK_LIBRARIES, INCLUDE_DIRECTORIES, INTERFACE_INCLUDE_DIRECTORIES, etc. to a cloned test executable.
Earlier I've written a question regarding testing of internal components of a library on SO here: https://stackoverflow.com/questions/54652349/how-to-unit-test-private-features-of-library-tdd-with-cmake
Here I concluded that solution 2 would work. But this stopped being valid when there contains multiple libraries in the build tree. So for my scenario, imagine a build tree with multiple additions of "Foo" from that SO question. Are there any solution I am grossly missing here, or what is the canonical solution to this problem? I would assume this is not a unusual case by any means.