Hi, I am looking for some feedback regarding unit testing libraries (e.g. Frameworks libraries, but not limited to). First, some background:
As long as on limits oneself to testing the public API of a library all is easy, linking and calling the exposed API just works. Some say that's all that should be tested, case closed. Unfortunately, in my experience that does not work out all the time. Unit testing requires some input data, and it is not always possible to provide the required data to the exposed API. One example would be files, files can be large, especially if there are many variations which need to be covered. Another one is extended attributes, e.g. KFileMetaData testing requires a writable filesystem with XAttr support (tmpfs only has limited XAttr support). The same probably applies to DBs and external (Web) servers, or anything that involves system calls. Public API may also limit the possibility to inject errors, or good coverage may be limited by combinatorial explosion. So there a definitely good reasons to not only test public API, but also internal functions. Hiding just the API is fairly simple, just make the relevant header private. But preferably, also the corresponding symbols in the created shared libraries are hidden. Hiding unexported/private symbols reduces runtime link time, and allows the compiler to remove unreachable code, due to inlining and/or LTO. On the other hand, these hidden functions can also no longer be linked to and called by any unit tests. So, now to my actual question - what are the preferred options for testing internal API? 1. Just link the test binary to the relevant source files + Trivial - May require long lists of sources, extra `target_include_directories` etc. 2. Create an intermediate CMake OBJECT library, which is linked to by the test binaries, and used for the exported shared library. The object library is not affected by symbol visibility + CMake properties like include directories still work - adds an extra intermediate target, less idiomatic 3. ? Kind regards, Stefan
signature.asc
Description: This is a digitally signed message part.
