\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.
+\warning this section is outdated. New unit tests should be written
+using the unit_test_framework component of Boost. There is no such
+example so far in our codebase, but that's definitely the way to go
+for the future. STOP USING XBT.
-If you want to create unit tests in the file src/xbt/toto.c, your
-changes should look similar to:
+If you want to test a specific function or set of functions, you need
+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
- src/xbt/xbt_strbuff.c
+@@ -11,6 +11,7 @@ set(FILES_CONTAINING_UNITTESTS
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(SIMGRID_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 */
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
- 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.\n
- The script located in <project/directory>/tools/cmake/tesh/generate_tesh.sh can
+ 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.\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/cmake/tesh/ directory, that can be useful to understand the tesh syntax.
+ 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
- category of tests together. The only way to do so in ctest is to
- use the -R argument that specifies a regular expression that the
- test names must match. For example, you can run all MSG test with
- "ctest -R msg". That explains the importance of the test names.
+ the following file:
+ @verbatim
+ <project/directory>/teshsuite/<interface eg msg>/CMakeLists.txt
+ @endverbatim
+ Make sure to pick a wise name for your test. It is often useful to
+ check a category of tests together. The only way to do so in ctest
+ is to use the -R argument that specifies a regular expression that
+ the test names must match. For example, you can run all MSG test
+ with "ctest -R msg". That explains the importance of the test
+ names.
Once the name is chosen, create a new test by adding a line similar to
the following (assuming that you use tesh as expected).
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>
to build and somehow test SimGrid on windows.
The result can be seen here: https://ci.inria.fr/simgrid/
-We have 3 projects on Jenkins:
+We have 2 interesting projects on Jenkins:
\li <a href="https://ci.inria.fr/simgrid/job/SimGrid-Multi/">SimGrid-Multi</a>
is the main project, running the tests that we spoke about.\n It is
configured (on Jenkins) to run the script <tt>tools/jenkins/build.sh</tt>
\li <a href="https://ci.inria.fr/simgrid/job/SimGrid-DynamicAnalysis/">SimGrid-DynamicAnalysis</a>
- runs the tests both under valgrind to find the memory errors and
- under gcovr to report the achieved test coverage.\n It is configured
+ should be called "nightly" because it does not only run dynamic
+ tests, but a whole bunch of long lasting tests: valgrind (memory
+ errors), gcovr (coverage), Sanitizers (bad pointer usage, threading
+ errors, use of unspecified C constructs) and the clang static analyzer.\n It is configured
(on Jenkins) to run the script <tt>tools/jenkins/DynamicAnalysis.sh</tt>
-\li <a href="https://ci.inria.fr/simgrid/job/SimGrid-Windows/">SimGrid-Windows</a>
- is an ongoing attempt to get Windows tested on Jenkins too.
In each case, SimGrid gets built in
/builds/workspace/$PROJECT/build_mode/$CONFIG/label/$SERVER/build
interface language is English) and tick the checkbox; then add a
groovy-expression to disable a specific configuration. For example, in
order to disable the "ModelChecker" build on host
-"small-freebsd-64-clang", use:
+"small-netbsd-64-clang", use:
\verbatim
-(label=="small-freebsd-64-clang").implies(build_mode!="ModelChecker")
+(label=="small-netbsd-64-clang").implies(build_mode!="ModelChecker")
+\endverbatim
+
+Just for the record, the slaves were created from the available
+template with the following commands:
+\verbatim
+#debian/ubuntu
+apt-get install gcc g++ gfortran automake cmake libboost-dev openjdk-8-jdk openjdk-8-jre libxslt-dev libxml2-dev libevent-dev libunwind-dev libdw-dev htop git python3 xsltproc libboost-context-dev
+#for dynamicanalysis:
+apt-get install jacoco libjacoco-java libns3-dev pcregrep gcovr ant lua5.3-dev sloccount
+
+#fedora
+dnf install libboost-devel openjdk-8-jdk openjdk-8-jre libxslt-devel libxml2-devel xsltproc git python3 libdw-devel libevent-devel libunwind-devel htop lua5.3-devel
+
+#netbsd
+pkg_add cmake gcc7 boost boost-headers automake openjdk8 libxslt libxml2 libunwind git htop python36
+
+#opensuse
+zypper install cmake automake clang boost-devel java-1_8_0-openjdk-devel libxslt-devel libxml2-devel xsltproc git python3 libdw-devel libevent-devel libunwind-devel htop binutils ggc7-fortran
+
+#freebsd
+pkg install boost-libs cmake openjdk8 automake libxslt libxml2 libunwind git htop python3 automake gcc6 flang elfutils libevent
+#+ clang-devel from ports
+
+#osx
+brew install cmake boost libunwind-headers libxslt git python3
\endverbatim
\subsection inside_tests_travis Travis
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
+
+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
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
-It should be noted that I miserably failed to use the environment
-provided by AppVeyor, since SimGrid does not build with Microsoft
-Visual Studio. Instead, we download a whole development environment
-from the internet at each build. That's an archive of already compiled
-binaries that are unpacked on the appveyor systems each time we start.
-We re-use the ones from the
-<a href="https://github.com/symengine/symengine">symengine</a>
-project. Thanks to them for compiling sane tools and constituting that
-archive, it saved my mind!
+We use \c Choco as a package manager on AppVeyor, and it is sufficient
+for us. In the future, we will probably move to the ubuntu subsystem
+of Windows 10: SimGrid performs very well under these settings, as
+tested on Inria's CI servers. For the time being having a native
+library is still useful for the Java users that don't want to install
+anything beyond Java on their windows.
\subsection inside_tests_debian Debian builders
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://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
+
*/
