X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/979ccd958739ad8e3434a81adea4249743c7daa5..458916c04f29576ae5949d7a395c4ed686f2e8b9:/docs/source/Contributors_Documentation.rst diff --git a/docs/source/Contributors_Documentation.rst b/docs/source/Contributors_Documentation.rst index f5d3447644..8a8f26605c 100644 --- a/docs/source/Contributors_Documentation.rst +++ b/docs/source/Contributors_Documentation.rst @@ -92,6 +92,50 @@ following the syntax described in this man page: ``man -l manpages/tesh.1`` Fina by modifying for example the ``examples/cpp/CMakeLists.txt`` file. The test name shall allow the filtering of tests with ``ctest -R``. Do not forget to run ``make distcheck`` once you're done to check that you did not forget to add your new files to the distribution. +Noteworthy tests +^^^^^^^^^^^^^^^^ + +Here is a short list of some typical tests in SimGrid, in the hope that they can give you some inspiration for your own tests. +Note that good tests rarely involve randomness, which makes it difficult to understand and fix problems when they occur. + +* Several **model tests** display the full computation and expected results for some simple cases. Check for example the tesh files + of `teshsuite/models/cm02-tcpgamma/ `_ + (about the impact of the :ref:`cfg=network/TCP-gamma` parameter), `teshsuite/models/wifi_usage/ + `_ (on the wifi network model), + `teshsuite/models/wifi_usage_decay/ `_ + (on the decay component of the wifi model, for highly congestioned APs), or `teshsuite/models/ptask_L07_usage/ + `_ (on parallel tasks). The goal of these tests + is to be easy to understand just by reading their output. + + `teshsuite/models/cloud-sharing/ `_ is a + bit special here, because it introduces a mini-DSL. Its purpose is to test the CPU sharing between competing tasks with and + without VMs. The model is not very complex, but the corresponding code is somewhat intricated, thus the need for such an + extensive testing. In this test, ``( [o]2 )4`` denotes a test with only one task (only one ``o``) on a VM with two cores (``[ + ]2``), which is itself on a PM with four cores (``( )4``). Likewise, ``( [oo]1 [ ]1 )2`` tests 2 VMs with one core each, one of + them being empty and the other containing 2 active tasks. Both VMs are located on a PM with two cores. |br| + For each of these tests, we ensure that the performance delivered to each task matches our expectations, and that the reported + amount of used cores is also correct to ensure correct energy predictions. + +* We also have several **torture tests**, such as `teshsuite/s4u/comm-pt2pt/comm-pt2pt.cpp + `_ which tests exhaustively each + case of a communication matching when no error is involved. Regular, asynchronous, detached communications, and communications + with a permanent receiver declared are tests, both with the send first and with the receive first. Again, we have a tiny DSL + to specify the tests to do (see the ``usage()`` function). + + `teshsuite/s4u/activity-lifecycle/ `_ + tortures all kind of activities (sleep, exec, comm and direct-comm). It kills their ressource at several instants, kills the + host hosting the running actor, test the activity after death, etc. This time also, we have a little DSL but this time in the + code: the source is heavily loaded with templates to make it easier to write many such tests, at the expense of readability. + + SimGrid also features a `chaos monkey `_ to apply torture testing to complex + applications. It is composed of a plugin (embeeded in any SimGrid simulation) that can be used to get info about the resources + and the timestamps at which actions happens, or to kill a given resource at a given time. It also features `a script + `_ that uses this information to launch a given + simulation many times, killing each resource at each timestamp to see how SimGrid and your code react to these failures. The + monkey can even run your simulation in Valgrind to detect problems that would be silent otherwise. Try passing + ``--cfg=plugin:cmonkey`` to your simulations for more information. We currently have a master-workers example (in both C++ and + Python) and a semaphore example (in C++ only) in ``teshsuite/s4u``. + Continuous integrations ^^^^^^^^^^^^^^^^^^^^^^^ @@ -145,3 +189,7 @@ Unsorted hints * If you break the logs, you want to define XBT_LOG_MAYDAY at the beginning of log.h. It deactivates the whole logging mechanism, switching to printfs instead. SimGrid then becomes incredibly verbose, but it you let you fixing things. + +.. |br| raw:: html + +