Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
get rid of surf_exit()
[simgrid.git] / doc / doxygen / inside_tests.doc
index 48756cc..43617ab 100644 (file)
@@ -41,131 +41,27 @@ ctest -R msg- -j5 --output-on-failure # You changed MSG and want to check that y
 
 @section inside_tests_rununit Running the unit tests
 
 
 @section inside_tests_rununit Running the unit tests
 
-All unit tests are packed into the testall binary, that lives at the
+All unit tests are packed into the unit-tests binary, that lives at the
 source root. These tests are run when you launch ctest, don't worry.
 
 @verbatim
 source root. These tests are run when you launch ctest, don't worry.
 
 @verbatim
-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.
+make unit-tests                 # Rebuild the test runner on need
+./unit-tests                    # Launch all tests
+./unit-tests --help             # revise how it goes if you forgot
 @endverbatim
 
 
 @section inside_tests_add_units Adding unit tests
 
 @endverbatim
 
 
 @section inside_tests_add_units Adding unit tests
 
-@warning this section is outdated. New unit tests should be written
-using the Catch2 library, that is included in the source tree. Please
-check for examples, listed at the end of tools/cmake/Tests.cmake.
-STOP USING XBT.
+Our unit tests are written using the Catch2 library, that is included
+in the source tree. Please check for examples, listed at the end of
+tools/cmake/Tests.cmake.
 
 
-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(FILES_CONTAINING_UNITTESTS
-   src/xbt/xbt_sha.c
-   src/xbt/config.c
-+  src/xbt/plouf.c
-   )
-
- if(SIMGRID_HAVE_MC)
-@endverbatim
-
-Then, you want to actually add your tests in the source file. All the
-tests must be protected by "#ifdef SIMGRID_TEST" so that they don't
-get included in the regular build. The line SIMGRID_TEST must also be
-written on the endif line for the extraction script to work properly. 
-
-Tests are subdivided in three levels. The top-level, called <b>test
-suite</b>, is created with the macro #XBT_TEST_SUITE. There can be
-only one suite per source file. A suite contains <b>test units</b>
-that you create with the #XBT_TEST_UNIT macro.  Finally, you start
-<b>actual tests</b> with #xbt_test_add. There is no closing marker of
-any sort, and an unit is closed when the next unit starts, or when the
-end of file is reached. 
-
-Once a given test is started with #xbt_test_add, you use
-#xbt_test_assert to specify that it was actually an assert, or
-#xbt_test_fail to specify that it failed (if your test cannot easily
-be written as an assert). #xbt_test_exception can be used to report
-that it failed with an exception. There is nothing to do to report
-that a given test succeeded, just start the next test without
-reporting any issue. Finally, #xbt_test_log can be used to report
-intermediate steps. The messages will be shown only if the
-corresponding test fails.
-
-Here is a recaping example, inspired from src/xbt/dynar.h (see that
-file for details).
-@code
-/* The rest of your module implementation */
-
-#ifdef SIMGRID_TEST
-
-XBT_TEST_SUITE("dynar", "Dynar data container");
-XBT_LOG_EXTERNAL_DEFAULT_CATEGORY(xbt_dyn); // Just the regular logging stuff
-
-XBT_TEST_UNIT("int", test_dynar_int, "Dynars of integers")
-{
-  int i, cpt;
-  unsigned int cursor;
-
-  xbt_test_add("==== Traverse the empty dynar");
-  xbt_dynar_t d = xbt_dynar_new(sizeof(int), NULL);
-  xbt_dynar_foreach(d, cursor, i) {
-    xbt_test_fail( "Damnit, there is something in the empty dynar");
-  }
-  xbt_dynar_free(&d);
-
-  xbt_test_add("==== Push %d int and re-read them",  NB_ELEM);
-  d = xbt_dynar_new(sizeof(int), NULL);
-  for (cpt = 0; cpt < NB_ELEM; cpt++) {
-    xbt_test_log("Push %d, length=%lu", cpt, xbt_dynar_length(d));
-    xbt_dynar_push_as(d, int, cpt);
-  }
-
-  for (cursor = 0; cursor < NB_ELEM; cursor++) {
-    int *iptr = xbt_dynar_get_ptr(d, cursor);
-    xbt_test_assert(cursor == *iptr,
-       "The retrieved value is not the same than the injected one (%u!=%d)",cursor, cpt);
-  }
-  
-  xbt_test_add("==== Check the size of that %d-long dynar",  NB_ELEM);
-  xbt_test_assert(xbt_dynar_size(d) == NB_ELEM);
-  xbt_dynar_free(&d); 
-}
-
-XBT_TEST_UNIT("insert",test_dynar_insert,"Using the xbt_dynar_insert and xbt_dynar_remove functions")
-{
-  xbt_dynar_t d = xbt_dynar_new(sizeof(unsigned int), NULL);
-  unsigned int cursor;
-  int cpt;
-
-  xbt_test_add("==== Insert %d int, traverse them, remove them",NB_ELEM);
-  // BLA BLA BLA
-}
-
-#endif  /* SIMGRID_TEST <-- that string must appear on the endif line */
-@endcode
-
-For more details on the macro used to write unit tests, see their
-reference guide: @ref XBT_cunit.  For details on on how the tests are
-extracted from the module source, check the tools/sg_unit_extractor.pl
-script directly.
-
-Last note: please try to keep your tests fast. We run them very very
-very often, and you should strive to make it as fast as possible, to
-not upset the other developers. Do not hesitate to stress test your
-code with such unit tests, but make sure that it runs reasonably fast,
-or nobody will run "ctest" before commiting code.
+It is important to keep your tests fast. We run them very very often,
+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 committing code.
 
 @section inside_tests_add_integration Adding integration tests
 
 
 @section inside_tests_add_integration Adding integration tests
 
@@ -193,10 +89,10 @@ 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
+   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
    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
    #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
@@ -234,7 +130,7 @@ ADD_TEST(my-test-name ${CMAKE_BINARY_DIR}/bin/tesh
 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.
 
 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. 
 
 We use several systems to automatically test SimGrid with a large set
 of parameters, across as many platforms as possible. 
@@ -242,9 +138,7 @@ We use <a href="https://ci.inria.fr/simgrid/">Jenkins on Inria
 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!
 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/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>
+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
@@ -309,23 +203,9 @@ pkg install boost-libs cmake openjdk8 automake libxslt libxml2 libunwind git hto
 brew install cmake boost libunwind-headers libxslt git python3 
 @endverbatim
 
 brew install cmake boost libunwind-headers libxslt git python3 
 @endverbatim
 
-@subsection inside_tests_travis Travis
-
-Travis is a free (as in free beer) Continuous Integration system that
-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/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
 
 @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
+Our configuration is in the file appveyor.yml as it should
 be, and the result is here: https://ci.appveyor.com/project/mquinson/simgrid
 
 We use @c Choco as a package manager on AppVeyor, and it is sufficient
 be, and the result is here: https://ci.appveyor.com/project/mquinson/simgrid
 
 We use @c Choco as a package manager on AppVeyor, and it is sufficient
@@ -354,9 +234,6 @@ 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: 
 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
+https://sonarcloud.io/dashboard?id=simgrid_simgrid
 
 */
 
 */