Use a unit test framework
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
mainfunction, along with exception handling.
- A failing
assertstatement terminates the code immediately. It then remains unclear if subsequent assertions would fail or succeed, so errors have to be fixed "one by one".
assertstatements have a trivial error report (like
assert(val == 1) failed!).
assertstatements are ignored when
NDEBUGis set as pre-processor variable. This makes the unit tests dependent on the build type. In particular, they always succeed for a
- No build organization. Ideally, unit tests are split into multiple separate test cases to avoid inter-dependencies between certain test operations.
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.