-\endverbatim
-
-\section inside_tests_rununit Running the unit tests
-
-All unit tests are packed into the testall binary, that lives in src/.
-These tests are run when you launch ctest, don't worry.
-
-\verbatim
-make testall # Rebuild the test runner on need
-./src/testall # Launch all tests
-./src/testall --help # revise how it goes if you forgot
-./src/testall --tests=-all # run no test at all (yeah, that's useless)
-./src/testall --dump-only # Display all existing test suite
-./src/testall --tests=-all,+dict # Only launch the tests from the dict testsuite
-./src/testall --tests=-all,+foo:bar # run only the bar test from the foo suite.
-\endverbatim
-
-
-\section inside_tests_add_units Adding unit tests
-
-If you want to test a specific function or set of functions, you need
-a unit test. Edit
-<project/directory>/tools/cmake/UnitTesting.cmake to add your
-source file to the TEST_CFILES list, and add the corresponding unit
-file to the TEST_UNITS list. For example, if your file is toto.c,
-your unit file will be toto_unit.c. The full path to your file must be
-provided, but the unit file will always be in src/ directly.
-
-If you want to create unit tests in the file src/xbt/toto.c, your
-changes should look similar to:
-
-\verbatim
---- a/tools/cmake/UnitTesting.cmake
-+++ b/tools/cmake/UnitTesting.cmake
-@@ -11,6 +11,7 @@ set(TEST_CFILES
- src/xbt/xbt_strbuff.c
- src/xbt/xbt_sha.c
- src/xbt/config.c
-+ src/xbt/toto.c
- )
- set(TEST_UNITS
- ${CMAKE_CURRENT_BINARY_DIR}/src/cunit_unit.c
-@@ -22,6 +23,7 @@ set(TEST_UNITS
- ${CMAKE_CURRENT_BINARY_DIR}/src/xbt_strbuff_unit.c
- ${CMAKE_CURRENT_BINARY_DIR}/src/xbt_sha_unit.c
- ${CMAKE_CURRENT_BINARY_DIR}/src/config_unit.c
-+ ${CMAKE_CURRENT_BINARY_DIR}/src/toto_unit.c
-
- ${CMAKE_CURRENT_BINARY_DIR}/src/simgrid_units_main.c
- )
-\endverbatim
-
-Then, you want to actually add your tests in the source file. All the
-tests must be protected by "#ifdef SIMGRID_TEST" so that they don't
-get included in the regular build. Then, you want to add a test suite
-that will contain a bunch of tests (in Junit, that would be a test
-unit) with the macro #XBT_TEST_SUITE, and populate it with a bunch of
-actual tests with the macro #XBT_TEST_UNIT (sorry for the mischosen
-names if you are used to junit). Just look at the dynar example (or
-any other) to see how it works in practice. Do not hesitate to stress
-test your code this way, but make sure that it runs reasonably fast,
-or nobody will run "ctest" before commiting code.
-
-For more details on the macro used to write unit tests, see their
-reference guide: @ref XBT_cunit. For details on on how the tests are
-extracted from the module source, check the tools/sg_unit_extractor.pl
-script directly.
-
-
-\section inside_tests_add_integration Adding integration tests
+@endverbatim
+
+@section inside_tests_rununit Running the unit tests
+
+All unit tests are packed into the unit-tests binary, that lives at the
+source root. These tests are run when you launch ctest, don't worry.
+
+@verbatim
+make unit-tests # Rebuild the test runner on need
+./unit-tests # Launch all tests
+./unit-tests --help # revise how it goes if you forgot
+@endverbatim
+
+
+@section inside_tests_add_units Adding unit tests
+
+Our unit tests are written using the Catch2 library, that is included
+in the source tree. Please check for examples, listed at the end of
+tools/cmake/Tests.cmake.
+
+It is important to keep your tests fast. We run them very very often,
+and you should strive to make them as fast as possible, to not bother
+the other developers. Do not hesitate to stress test your code, but
+make sure that it runs reasonably fast, or nobody will run "ctest"
+before commiting code.
+
+@section inside_tests_add_integration Adding integration tests