Use a unit test framework
Description
We currently rely on building our own complete executables when writing unit tests. In most tests, we perform checks via the assert
function. This has several downsides:
- We always have to write a
main
function, along with exception handling. - A failing
assert
statement terminates the code immediately. It then remains unclear if subsequent assertions would fail or succeed, so errors have to be fixed "one by one". -
assert
statements have a trivial error report (likeassert(val == 1) failed!
). -
assert
statements are ignored whenNDEBUG
is set as pre-processor variable. This makes the unit tests dependent on the build type. In particular, they always succeed for aRelease
build. - No build organization. Ideally, unit tests are split into multiple separate test cases to avoid inter-dependencies between certain test operations.
Proposal
Use a unit test framework to run unit tests. The large players are Boost Test and Google Test. Both have nearly the same features. I have some experience with Boost Test as we use it in Utopia very successfully. It's also very easy to write unit tests with it, see the Utopia docs and the related MR https://ts-gitlab.iup.uni-heidelberg.de/utopia/utopia/merge_requests/251.
The downside to Boost Test is that we introduce a rather large dependency (the Boost library). However, it would only be required for testing, not for simply running DORiE, just like dune-testtools
. In that sense, Google Test would be the more lightweight solution.
I would suggest to only adapt one test when switching to the new framework, and then require tests written in the future to adhere to it. The other existing tests can be adapted over time. We then also need instructions for developers. In case of DORiE, this should then be in the Doxygen documentation.
A preview can be found at !155 (closed).
How to test the implementation?
Unit tests with new framework succeed.