tests and corner cases integration tests are located in teshsuite/.
For each integration test, we ensure that the output exactly matches
the defined expectations. Since SimGrid displays the timestamp of
-every loggued line, this ensures that every change of the models'
+every logged line, this ensures that every change of the models'
prediction will be noticed. All these tests should ensure that SimGrid
is safe to use and to depend on.
\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.
+All unit tests are packed into the testall binary, that lives at the
+source root. 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.
+make testall # Rebuild the test runner on need
+./testall # Launch all tests
+./testall --help # revise how it goes if you forgot
+./testall --tests=-all # run no test at all (yeah, that's useless)
+./testall --dump-only # Display all existing test suites
+./testall --tests=-all,+dict # Only launch the tests from the dict test suite
+./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:
+a unit test. Edit the file tools/cmake/UnitTesting.cmake to
+add your source file to the FILES_CONTAINING_UNITTESTS list. For
+example, if you want to create unit tests in the file src/xbt/plouf.c,
+your changes should look like that:
\verbatim
--- a/tools/cmake/UnitTesting.cmake
+++ b/tools/cmake/UnitTesting.cmake
-@@ -11,6 +11,7 @@ set(TEST_CFILES
+@@ -11,6 +11,7 @@ set(FILES_CONTAINING_UNITTESTS
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
++ src/xbt/plouf.c
)
+
+ if(HAVE_MC)
\endverbatim
Then, you want to actually add your tests in the source file. All the
intermediate steps. The messages will be shown only if the
corresponding test fails.
-Here is a recaping example, inspired from the dynar implementation.
+Here is a recaping example, inspired from src/xbt/dynar.h (see that
+file for details).
@code
/* The rest of your module implementation */
even comes with a man page. TESH ensures that the output produced by a
command perfectly matches the expected output. This is very precious
to ensure that no change modifies the timings computed by the models
-without notice.
+without notice.
To add a new integration test, you thus have 3 things to do:
examples/ and modify the cmake files as explained on this page:
\ref inside_cmake_examples. If you feel like you should write a
torture test that is not interesting to the users (because nobody
- would sainly write something similar in user code), then put it under
+ would sanely write something similar in user code), then put it under
teshsuite/ somewhere.
+
- <b>Write the tesh file</b>, containing the command to run, the
provided input (if any, but almost no SimGrid test provide such an
input) and the expected output. Check the tesh man page for more
- details. \n
+ 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, nor memory adresses as
+ not output machine dependent informations such as absolute data path, nor memory adresses 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 #XBT_LOG_ISENABLED() macro), or the
modification of the log formats to hide the timings when they
- depend on the host machine.
+ depend on the host machine.\n
+ The script located in <project/directory>/tools/tesh/generate_tesh can
+ help you a lot in particular if the output is large (though a smaller output is preferable).
+ There are also example tesh files in the <project/directory>/tools/tesh/ directory, that can be useful to understand the tesh syntax.
+
- <b>Add your test in the cmake infrastructure</b>. For that, modify
the file <project/directory>/tools/cmake/Tests.cmake. Make sure to
pick a wise name for your test. It is often useful to check a
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/mquinson/simgrid">Travis</a> to
+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>
+miss issues. And we use <a href="https://ci.appveyor.com/project/simgrid/simgrid">AppVeyor</a>
to build and somehow test SimGrid on windows.
\subsection inside_tests_jenkins Jenkins on the Inria CI servers
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/mquinson/simgrid
+result is here: https://travis-ci.org/simgrid/simgrid
\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
-be, and the result is here: https://ci.appveyor.com/project/mquinson/simgrid
+be, and the result is here: https://ci.appveyor.com/project/simgrid/simgrid
It should be noted that I miserably failed to use the environment
provided by AppVeyor, since SimGrid does not build with Microsoft
The build results are here:
https://buildd.debian.org/status/package.php?p=simgrid
+\subsection inside_tests_sonarqube SonarQube
+
+SonarQube is an open-source code quality analysis solution. Their nice
+code scanners are provided as plugin. The one for C++ is not free, but
+open-source project can use it at no cost. That is what we are doing.
+
+Don't miss the great looking dashboard here:
+https://nemo.sonarqube.org/overview?id=simgrid
+
+This tool is enriched by the script @c tools/internal/travis-sonarqube.sh
+that is run from @c .travis.yml
+
*/
