codacy

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

diff --git a/doc/doxygen/inside_tests.doc b/doc/doxygen/inside_tests.doc
index 657158c..c8195c2 100644 (file)
--- a/doc/doxygen/inside_tests.doc
+++ b/doc/doxygen/inside_tests.doc
@@ -72,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


@@ -194,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).