So here are two examples on how the unit tests would work with Catch.

Basically the process I followed was divide the unit tests in pieces and each piece is defined as a test case. Also I added tags, which are used to classify the test and that way an specific tag can be run, example:

> ./unit_tests_catch 
===============================================================================
All tests passed (28 assertions in 8 test cases)

> ./unit_tests_catch --list-tags
All available tags:
   7  [color]
   1  [error]
   1  [general]
   7  [graphics]
4 tags

> ./unit_tests_catch [color]
===============================================================================
All tests passed (25 assertions in 7 test cases)

> ./unit_tests_catch [error]
===============================================================================
All tests passed (3 assertions in 1 test case)

We can discuss on how the tests should be tagged, I think per class and per documentation group is a good idea.

Also, you might note that all tests are compiled to a single executable, contrary to the previous approach where all tests had their own executable. I think this is better as it allows to leverage Catch's full power (it also might require better CMake magic to specify arguments for the final executable, but I'm a newbie at it).

For the constexpr I think is a good idea to keep them in a separate executable. If a constexpr test brakes only the compilation of that test should be broken.

For the live tests we could have a single Catch executable for them or merge them with the unit tests.