X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/ce3b234c639f0d20b4fc60704294b0cb32d4b2cb..befbbbe1fbb31663a8f91e24ce12df271cf4ae79:/doc/doxygen/inside_tests.doc diff --git a/doc/doxygen/inside_tests.doc b/doc/doxygen/inside_tests.doc index d99b23762e..c8195c2dd2 100644 --- 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 +\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 @@ -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 - src/xbt/xbt_strbuff.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 @@ -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 - 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 /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 /tools/tesh/ directory, that can be useful to understand the tesh syntax. - Add your test in the cmake infrastructure. For that, modify - the file /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 + /teshsuite//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). @@ -248,7 +256,7 @@ refer to the CI documentation. 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 SimGrid-Multi is the main project, running the tests that we spoke about.\n It is configured (on Jenkins) to run the script tools/jenkins/build.sh @@ -256,8 +264,6 @@ We have 3 projects on Jenkins: runs the tests both under valgrind to find the memory errors and under gcovr to report the achieved test coverage.\n It is configured (on Jenkins) to run the script tools/jenkins/DynamicAnalysis.sh -\li SimGrid-Windows - 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 @@ -270,10 +276,10 @@ 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 -"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 \subsection inside_tests_travis Travis @@ -284,6 +290,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 +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 @@ -291,15 +301,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 -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 -symengine -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 @@ -313,4 +319,16 @@ only the most important breakages. 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 + */