@section inside_tests_add_units Adding unit tests
-@warning this section is outdated. New unit tests should be 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.
+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.
-Last note: please try to keep your tests fast. We run them very very
-very often, and you should strive to make it as fast as possible, to
-not upset the other developers. Do not hesitate to stress test your
-code with such unit tests, but make sure that it runs reasonably fast,
-or nobody will run "ctest" before commiting code.
+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 committing code.
@section inside_tests_add_integration Adding integration tests
details.@n
Tesh is sometimes annoying as you have to ensure that the expected
output will always be exactly the same. In particular, your should
- not output machine dependent informations such as absolute data
- path, nor memory adresses as they would change on each run. Several
+ not output machine dependent information such as absolute data
+ path, nor memory addresses as they would change on each run. Several
steps can be used here, such as the obfucation of the memory
- adresses unless the verbose logs are displayed (using the
+ addresses unless the verbose logs are displayed (using the
#XBT_LOG_ISENABLED() macro), or the modification of the log formats
to hide the timings when they depend on the host machine.@n
The script located in <project/directory>/tools/tesh/generate_tesh can
As usual, you must run "make distcheck" after modifying the cmake files,
to ensure that you did not forget any files in the distributed archive.
-@section inside_tests_ci Continous Integration
+@section inside_tests_ci Continuous Integration
We use several systems to automatically test SimGrid with a large set
of parameters, across as many platforms as possible.
open-source project can use it at no cost. That is what we are doing.
Don't miss the great looking dashboard here:
-https://sonarcloud.io/dashboard?id=simgrid
+https://sonarcloud.io/dashboard?id=simgrid_simgrid
This tool is enriched by the script @c tools/internal/travis-sonarqube.sh
that is run from @c .travis.yml
