Merge branch 'actor-yield' of github.com:Takishipp/simgrid into actor-yield

[simgrid.git] / doc / doxygen / inside_tests.doc

diff --git a/doc/doxygen/inside_tests.doc b/doc/doxygen/inside_tests.doc
index 9b0cc77..38732f6 100644 (file)
--- a/doc/doxygen/inside_tests.doc
+++ b/doc/doxygen/inside_tests.doc
@@ -57,6 +57,11 @@ make testall                    # Rebuild the test runner on need
 
 \section inside_tests_add_units Adding unit tests
 
 
 \section inside_tests_add_units Adding unit tests
 

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


@@ -67,13 +72,12 @@ your changes should look like that:
 --- a/tools/cmake/UnitTesting.cmake
 +++ b/tools/cmake/UnitTesting.cmake
 @@ -11,6 +11,7 @@ set(FILES_CONTAINING_UNITTESTS
 --- a/tools/cmake/UnitTesting.cmake
 +++ b/tools/cmake/UnitTesting.cmake
 @@ -11,6 +11,7 @@ set(FILES_CONTAINING_UNITTESTS

-   src/xbt/xbt_strbuff.c

    src/xbt/xbt_sha.c
    src/xbt/config.c
 +  src/xbt/plouf.c
    )
 
    src/xbt/xbt_sha.c
    src/xbt/config.c
 +  src/xbt/plouf.c
    )
 

- if(HAVE_MC)
+ if(SIMGRID_HAVE_MC)

 \endverbatim
 
 Then, you want to actually add your tests in the source file. All the
 \endverbatim
 
 Then, you want to actually add your tests in the source file. All the


@@ -189,23 +193,27 @@ To add a new integration test, you thus have 3 things to do:
    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
    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 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
+   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/tesh/ directory, that can be useful to understand the tesh syntax.
    
  - <b>Add your test in the cmake infrastructure</b>. For that, modify
    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
-   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).
 
 Once the name is chosen, create a new test by adding a line similar to
 the following (assuming that you use tesh as expected).


@@ -236,7 +244,7 @@ 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
 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/simgrid/simgrid">AppVeyor</a>
+miss issues. And 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
 to build and somehow test SimGrid on windows. 
 
 \subsection inside_tests_jenkins Jenkins on the Inria CI servers


@@ -248,16 +256,16 @@ refer to the <a href="https://wiki.inria.fr/ciportal/">CI documentation</a>.
 
 The result can be seen here: https://ci.inria.fr/simgrid/
 
 
 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>
 \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>
     (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 
 
 In each case, SimGrid gets built in
 /builds/workspace/$PROJECT/build_mode/$CONFIG/label/$SERVER/build 


@@ -270,10 +278,35 @@ model-checking on non-linux systems), go to your Project and click on
 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
 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
 
 \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
 \endverbatim
 
 \subsection inside_tests_travis Travis


@@ -284,6 +317,10 @@ 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
 
 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
 \subsection inside_tests_appveyor AppVeyor
 
 AppVeyor aims at becoming the Travis of Windows. It is maybe less


@@ -291,15 +328,11 @@ 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/simgrid/simgrid
 
 Windows. Our configuration is in the file appveyor.yml as it should
 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
-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, but
+unfortunately we have no continuous integration service providing it
+yet, so we cannot drop AppVeyor yet.

 
 \subsection inside_tests_debian Debian builders
 
 
 \subsection inside_tests_debian Debian builders