@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.
servers</a> as a workhorse: it runs all of our tests for many
configurations. It takes a long time to answer, and it often reports
issues but when it's green, then you know that SimGrid is very fit!
-We use <a href="https://travis-ci.org/simgrid/simgrid">Travis</a> to
-quickly run some tests on Linux and Mac. It answers quickly but may
-miss issues. And we use <a href="https://ci.appveyor.com/project/mquinson/simgrid">AppVeyor</a>
+We use <a href="https://ci.appveyor.com/project/mquinson/simgrid">AppVeyor</a>
to build and somehow test SimGrid on windows.
@subsection inside_tests_jenkins Jenkins on the Inria CI servers
brew install cmake boost libunwind-headers libxslt git python3
@endverbatim
-@subsection inside_tests_travis Travis
-
-Travis is a free (as in free beer) Continuous Integration system that
-open-sourced project can use freely. It is very well integrated in the
-GitHub ecosystem. There is a plenty of documentation out there. Our
-configuration is in the file .travis.yml as it should be, and the
-result is here: https://travis-ci.org/simgrid/simgrid
-
-The .travis.yml configuration file can be useful if you fail to get
-SimGrid to compile on modern mac systems. We use the @c brew package
-manager there, and it works like a charm.
-
@subsection inside_tests_appveyor AppVeyor
-AppVeyor aims at becoming the Travis of Windows. It is maybe less
-mature than Travis, or maybe it is just that I'm less trained in
-Windows. Our configuration is in the file appveyor.yml as it should
+Our configuration is in the file appveyor.yml as it should
be, and the result is here: https://ci.appveyor.com/project/mquinson/simgrid
We use @c Choco as a package manager on AppVeyor, and it is sufficient
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
-
-This tool is enriched by the script @c tools/internal/travis-sonarqube.sh
-that is run from @c .travis.yml
+https://sonarcloud.io/dashboard?id=simgrid_simgrid
*/