[Mikolaj-A-Kowalski]

Adds a skeleton (for now basically empty) to enable unit testing.

Developing the tripolar functionality I have found myself in want of being able to test the components of the algorithm (utility functions basically). The existing /integration/regression test suite is not really fit for that purpose.

Since the test folder is busy as it is I though it will be cleaner to put unit tests in a separate directory.

Naturally things refuse to be easy and there is a complication related to how we compile the project.

We cannot link the unit_tests executable against the shared library target because most of the functions that we wish to test are not part of the library's public API and hence are compiled with "hidden" visibility. As the result, if we try to use them in tests, this results in linking errors (symbols not being found due to visibility).

The solution at the moment is to introduce a 2nd, static library, which we can use to collect all sources, include directories and dependencies and feed them when compiling executables (decomp tool and unit_tests for the moment).

To discuss in review

• Removing the dummy test before merging? I have put it there only to verify that symbols from the library are accessible.
• Trying to avoid recompiling the sources twice (once for SHARED and STATIC libraries). I am not sure it will be easy. Furthermore it may not be really what we want. We do compile executables with position independent code -fPIC at the moment, but it is not something we need to do)

[Mikolaj-A-Kowalski]

Trying to avoid recompiling the sources twice (once for SHARED and STATIC libraries). I am not sure it will be easy. Furthermore it may not be really what we want. We do compile executables with position independent code -fPIC at the moment, but it is not something we need to do)

Ad above, just providing a static library as a dependency of a dynamic library runs into an issue that there are no "extra" sources in the dynamic library target. CMake complains about lack of sources in that case :-/

[TomMelt]

thanks @Mikolaj-A-Kowalski this will be extremely useful for the decomp tool.

[jatkinson1000]

This seems sensible to me @Mikolaj-A-Kowalski and happy for merge.

Given the small source size I think a double compile is acceptable for now, and allows for a smoother integration with existing tests(?).

Happy for you to leave the dummy test for now and remove in a subsequent PR.

I see the building of unit tests is done, but are unit tests also included in the running (via ctest or similar)? Yes I think so, my CMake was a little fuzzy!