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.
+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
