RFC: Library unit testing and symbol visibility

[Stefan Brüns]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20230723/d0070b89/attachment.sig>