What buildsystem design techniques are there (using CMake) to test functionality that is internal to my shared library?

There is a possibility to hide some symbols in a shared library if they are not considered to be called from outside. But while the symbols are not required for the client of the library, they may be needed for tests.

For example, in my case, I have a library with a small public api and large inner logic. In order to write unit tests for the inner logic, I (think I) have to link the shared library to the test executable and somehow call hidden functions/classes.

The solution I've been using is to introduce a variable in CMake "build_tests" and if it is ON, then all symbols default to being visible for shared libraries. Otherwise I hide them.

What other ways exist to deal with this issue, and how do they compare? (what tradeoffs do they make?)

> My solution is to introduce a variable in CMAKE "build_tests" and if it is ON, then symbols are not hidden.

The disadvantage of this is that for a single generated buildsystem, you basically have to choose between what you'd like to see for release (with symobls visible on an as-needed basis) and what is usable to you for testing. You'd have to generate a buildsystem for testing, and one for release (if I understand correctly), which doesn't seem ideal. The same non-idealness would be the case if you created a visibility macro that only makes something visible for test builds.

It was brought up in comments that some people don't see a need to test internals- and that only things that are part of the interface of a library need to / should be tested. I think it can be useful to test lower-level parts of a library that aren't part of the library's interface.

The thing is, for a single shared library target in a single generated buildsystem, each symbol will either be visible or it won't. So if you want to just have a single generated buildsystem where you build your shared library without compromising on what you make visible from it, but also be able to test its internals, you either need to change the way you build the shared library, or change the way you build your test executables.

What's practical will depend on the characteristics of your library and the internals you want to test.

You could try to refactor your inner logic into its own static library, and have your shared library wrap the static library. Then the shared library would be what the users of your project use, and the static library would be what you use for testing, where you're not inhibited by any visibility mechanisms. The binary you'd be testing would be a test executable linked to a static library, and so there would probably be differences in things like how certain things get translated to machine code if you build with any optimizations. Just be aware of that. This approach might take more programming work to do the separation and wrapping.

Another thing you could consider is to just add specific source files implementing that internal logic of the library into a dedicated test executable (or multiple test executables for various source files). This could be pragmatic if the source files for your internals are pretty self contained from each other. If you don't use link-time optimizations and you want to do things really granularly, with many test executables- for example- one for each source file, this could end up with more compilation time than the previously mentioned approach with a static library- again, the details of the difference will depend on the characteristics of your project. There are testing libraries that are designed with enabling writing tests in the same file as sources to help you with this, such as doctest.

I'm not very sure if these are good ideas at scale though, since I don't have experience with large projects.