Index: src/documentation/tests/code-tests.dox
===================================================================
--- src/documentation/tests/code-tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
+++ src/documentation/tests/code-tests.dox	(revision 5982c5922d9ec80de77b5dbb7184f7cc879c6eac)
@@ -22,10 +22,12 @@
  * -# Every .cpp files must include \b config.h and \b CodePatterns/MemDebug.hpp
  * -# Every .hpp files must include \b config.h
+ * -# Every .dox file contains a (correctly formatted: YYYY-MM-DD) date stamp.
  *
  * These make sure that the memory debugger is catching every movement on the
- * heap and that every module knows about the behavior controling defines that
- * are checked by autoconf and written to \b config.h in the build directory.
+ * heap and that every module knows about the behavior controling \e #define's that
+ * are checked by autoconf and written to \b config.h in the build directory. And
+ * also that for every documentation file it is known when it was current.
  *
- * \section Directory structure
+ * \section codetest-structure Directory structure
  *
  * The code tests are contained in \b tests/CodeChecks. Therein are all test
@@ -33,15 +35,66 @@
  * Mostly, these look through files
  *
- * \section Launching all tests
+ * \section codetest-launch-all Launching all tests
  *
- *  TODO: Documentation - explain how to launch all code tests.
+ *  In order to launch all tests, simply do:
+ *  -# Enter \b tests/CodeChecks in your build directory
+ *  -# Run
+ *    \code make check \endcode
+ *    there
  *
- * \section Launching some tests
+ * \section codetest-launch-some Launching some tests
  *
- *  TODO: Documentation - explain how to launch some code tests
+ *  Launching a single or just some of the tests is only a little bit more
+ *  complicated. Proceed as follows:
+ *  -# Enter \b tests/CodeChecks in your build directory
+ *  -# Run
+ *  \code ../../../tests/CodeChecks/testsuite <option> AUTOTEST_PATH="<buildpath>/src" \endcode,
+ *  where \a <option> is explained in the subsections below and \a <buildpath> is
+ *  the build path (i.e. the variable \a AUTOTEST_PATH should contain the path to
+ *  the executable).
  *
- * \section Inspecting results
+ *  \subsection regressiontest-launch-by-number ... by number
  *
- *  TODO: Documentation - explain how to inspect code test results.
+ *    Tests can be launched by specifying their test number, e.g. then \a <option>
+ *    might be \a 1 or \a 1-2 or just nothing for all of them.
+ *
+ *  \subsection regressiontest-launch-by-keyword .. by keyword
+ *
+ *    Tests may as well be launched by some keywords, e.g. each code check has
+ *    a specific keyword which is given via \b AT_KEYWORD directive of Autotest.
+ *    I.e. we may launch the test on \b config.h presence via the \a <option>
+ *    \a -k \a config_h. Also multiple keywords may be given.
+ *
+ * \section codetest-results Inspecting results
+ *
+ *  The testsuite can be launched with the additional option of \a -d which leaves the
+ *  directory of the test present even though the test has passed for inspection.
+ *
+ *  If a test fails, in whatever way it was launched, will leave in the build directory
+ *  a folder \b tests/CodeChecks/testsuite.dir/<nr> where \a <nr> is the number of the
+ *  test (padded maybe with some zeros).
+ *
+ *  In the current state tests will fail because one file does not include \b
+ *  config.h or \b MemDebug.hpp. Hence, check the testsuite's log to get the file
+ *  name of the culprit at its very bottom.
+ *
+ * \section unittest-add Adding new tests
+ *
+ *  \attention Name convention of files, (no spaces, use underscore) e.g.
+ *  \b testsuite-config_h.at
+ *  - the test script file should be called as follows:
+ *    -# testsuite-...
+ *    -# followed by the construct that is tested.
+ *
+ *  In order to add a new test, you have to do the following:
+ *  -# Add a new \b testsuite-....at script to the folder \b tests/CodeChecks
+ *    (have a look at the present ones and see above for help on the commands
+ *    recognized by Autotest. \e Mind \e giving it a suitable \e keyword!).
+ *  -# Add the file to Makefile.am such that the testsuite is re-created when
+ *    you change the test script.
+ *  -# Add the file as an \e m4_include directive to testsuite.at.
+ *
+ *
+ * \date 2011-10-31
  *
  */
Index: src/documentation/tests/regression-tests.dox
===================================================================
--- src/documentation/tests/regression-tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
+++ src/documentation/tests/regression-tests.dox	(revision 5982c5922d9ec80de77b5dbb7184f7cc879c6eac)
@@ -25,5 +25,5 @@
  * regression tests.
  *
- * \section Directory structure
+ * \section regressiontest-structure Directory structure
  *
  * They are contained in the source folder \b tests/regression. There are
@@ -36,5 +36,64 @@
  *  named test script one directory level higher.
  *
- *  \section Adding a new test
+ *  \section regressiontest-launch-all Launching all tests
+ *
+ *  Launching all regression tests is as simple as:
+ *  -# Enter the build directory
+ *  -# There, enter \b tests/regression
+ *  -# Run
+ *  \code make check \endcode
+ *  (at you liberty with option \a -j8 or similar for running the tests in
+ *  parallel.
+ *
+ *  \section regressiontest-launch-some Launching a specific tests
+ *
+ *  Launching a single or just some of the tests is only a little bit more
+ *  complicated. There are two options: either by the test number which however
+ *  changes when new tests are added, and by keywords.
+ *
+ *  Then proceed as follows:
+ *  -# Enter the build directory
+ *  -# There, enter \b tests/regression
+ *  -# Run
+ *  \code ../../../tests/regression/testsuite <option> AUTOTEST_PATH="<buildpath>/src" \endcode,
+ *  where \a <option> is explained in the subsections below and \a <buildpath>
+ *  is the build path (i.e. the variable \a AUTOTEST_PATH should contain the
+ *  path to the executable).
+ *
+ *  \subsection regressiontest-launch-by-number ... by number
+ *
+ *    Tests can be launched by specifying their test number, e.g. then \a <option>
+ *    might be \a 283 or \a 283-284 or \a 283,285-286 or alike
+ *
+ *  \subsection regressiontest-launch-by-keyword .. by keyword
+ *
+ *    Tests may as well be launched by some keywords, e.g. each Action has a
+ *    specific token which is also one of its keyword (see above for the
+ *    policy). I.e. we may launch the test on fill-void via the \a <option>
+ *    \a -k \a fill-void. Also multiple keywords may be given.
+ *
+ * \section regressiontest-results Inspecting test results
+ *
+ *  The testsuite can be launched with the additional option of \a -d which
+ *  leaves the directory of the test present even though the test has passed
+ *  for inspection.
+ *
+ *  If a test fails, in whatever way it was launched, will leave in the build
+ *  directory a folder \b tests/regression/testsuite.dir/<nr> where \a <nr> is
+ *  the number of the test (padded maybe with some zeros).
+ *
+ * \section regressiontest-add Adding a new test
+ *
+ *  \attention Name convention of files and directories, e.g.
+ *  \b tests/regression/Parser/Pdb with \b testsuite-parser-pdb-save.at
+ *  - the test directory should either be called as the token of the Action it
+ *    tests or a unique and brief description but with no spaces, no dashes,
+ *    but CamelCase (i.e. Capitalize each new word)
+ *  - the test script file should be called as follows:
+ *    -# testsuite-...
+ *    -# ...each directory (non-capital letters) with a dash...
+ *    -# ..the name of the test directory...
+ *    -# a further description of there are multiple test scripts in the
+ *      test directory.
  *
  *  Adding a new regression tests consists of the following items:
@@ -51,47 +110,6 @@
  *  testsuite is automatically re-compiled when one of the test files has changed.
  *
- *  \section Launching all tests
  *
- *  Launching all regression tests is as simple as:
- *  -# Enter the build directory
- *  -# There, enter \b tests/regression
- *  -# Run
- *  \code make check \endcode
- *  (at you liberty with option \a -j8 or similar for running the tests in parallel.
- *
- *  \section Launching a specific tests
- *
- *  Launching a single or just some of the tests is only a little bit more complicated.
- *  There are two options: either by the test number which however changes when new
- *  tests are added, and by keywords.
- *
- *  Then proceed as follows:
- *  -# Enter the build directory
- *  -# There, enter \b tests/regression
- *  -# Run
- *  \code ../../../tests/regression/testsuite <option> AUTOTEST_PATH="<buildpath>/src" \endcode,
- *  where \a <option> is explained in the subsections below and \a <buildpath> is the build
- *  path (i.e. the variable \a AUTOTEST_PATH should contain the path to the executable).
- *
- *  \subsection ... by number
- *
- *    Tests can be launched by specifying their test number, e.g. then \a <option>
- *    might be \a 283 or \a 283-284 or \a 283,285-286 or alike
- *
- *  \subsection .. by keyword
- *
- *    Tests may as well be launched by some keywords, e.g. each Action has a specific
- *    token which is also one of its keyword (see above for the policy). I.e. we may
- *    launch the test on fill-void via the \a <option> \a -k \a fill-void. Also
- *    multiple keywords may be given.
- *
- * \section Inspecting test results
- *
- *  The testsuite can be launched with the additional option of \a -d which leaves the
- *  directory of the test present even though the test has passed for inspection.
- *
- *  If a test fails, in whatever way it was launched, will leave in the build directory
- *  a folder \b tests/regression/testsuite.dir/<nr> where \a <nr> is the number of the
- *  test (padded maybe with some zeros).
+ * \date 2011-10-31
  *
  */
Index: src/documentation/tests/tests.dox
===================================================================
--- src/documentation/tests/tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
+++ src/documentation/tests/tests.dox	(revision 5982c5922d9ec80de77b5dbb7184f7cc879c6eac)
@@ -25,17 +25,20 @@
  * testing. Tests are regarded here as a kind of contract. The code itself is
  * just one hand in two hands shaking, the other hand is resembled by the tests
- * that checks whether the code does exactly what it's supposed to do. Without
- * testing a larger project is impossible because it cannot evolve. With
- * increasing size, a project must be refactored
- * (http://en.wikipedia.org/wiki/Code_refactoring) such that new code does not
- * have to wiggle itself around the same old issues that are present from the
- * start. Before one starts refactoring, it must be assured by some means that
- * the code before and after behaves the same with respect to its intended
- * functionality. These means are the tests.
+ * that check whether the code does exactly what it's supposed to do. Without
+ * testing a larger project is impossible because it cannot evolve: The old
+ * addage and compromises grow and grow. With increasing size, a project must be
+ * refactored (http://en.wikipedia.org/wiki/Code_refactoring) such that new code
+ * does not have to wiggle itself around the same old issues that are
+ * inadvertently and unavoidably present from the start. Before one starts
+ * refactoring, it must be assured by some means that the code before and after
+ * behaves the same with respect to its intended functionality. These means are
+ * the tests.
  *
- * Unit tests (http://en.wikipedia.org/wiki/Unit_testing) tests single
- * components (e.g. classes), dependencies on other classes are often just
- * mimicked via so-called stubs. These test whether a component always behaves
- * as desired.
+ * Unit tests (http://en.wikipedia.org/wiki/Unit_testing) check on single
+ * components (e.g. classes), dependencies of the components on other classes
+ * with the test frame are often just mimicked via so-called stubs (sort of
+ * dummy components that don't calculate or do anything but return an expected
+ * result suitable for this test only, see http://en.wikipedia.org/wiki/Test_stubs).
+ * These test whether a component always behaves as desired.
  *
  * Regression test (http://en.wikipedia.org/wiki/Regression_testing) on the other
@@ -45,9 +48,11 @@
  * has not changed the outcome of older functions.
  *
+ * \section tests-launch-all Launching all tests
+ *
  * Note that all tests can be launched via
  * \code make check \endcode
  * in the top build directory.
  *
- * \section Policy on launching tests
+ * \section tests-policy Policy on launching tests
  *
  * Note that the above run of \e all \e tests \e should \e pass for each and
@@ -60,3 +65,5 @@
  * runs fine and produces a distributable archive.
  *
+ * \date 2011-10-31
+ *
  */
Index: src/documentation/tests/unit-tests.dox
===================================================================
--- src/documentation/tests/unit-tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
+++ src/documentation/tests/unit-tests.dox	(revision 5982c5922d9ec80de77b5dbb7184f7cc879c6eac)
@@ -18,5 +18,5 @@
  * Unit tests are done via the CppUnit framework (http://cppunit.sourceforge.net/doc/1.8.0/).
  *
- * \section Directory structure
+ * \section unittest-structure Directory structure
  *
  *  Unit tests are always located in a subfolder \b unittests of the component
@@ -24,9 +24,5 @@
  *  resides in \b src/Parser/unittests.
  *
- * \section Adding new tests
- *
- *  TODO: Documentation - explain how to add tests.
- *
- * \section Launching all tests
+ * \section unittest-launch-all Launching all tests
  *
  *  All unit tests can be launched as follows:
@@ -39,5 +35,5 @@
  * This will run all present unit tests one after the other.
  *
- * \section Launching some tests
+ * \section unittest-launch-some Launching some tests
  *
  *  If only some of the tests should be checked, then they have to be launched by
@@ -56,8 +52,52 @@
  *  libraries, which have not been installed so far, are found.
  *
- * \section Inspecting results
+ * \section unittest-results Inspecting results
  *
  *  Results of the test are shown during run. An \a Ok(2) indicates that
  *  two tests for the single launched testsuite passed.
  *
+ * \section unittest-add Adding new tests
+ *
+ *  \attention Name convention of files, (no spaces, use CamelCase) e.g.
+ *  \b AnalysisBondsUnitTest
+ *  - the unit test module should be called as follows:
+ *    -# either the name of the component or the module
+ *    -# followed by UnitTest.
+ *  - the test class should be called as follows:
+ *    -# the name of the class it tests
+ *    -# followed by Test.
+ *
+ *  Adding a new test is as easy as this:
+ *  -# Create a new module for declaration and definition of the unit test
+ *    in a suitable \b unittests subfolder (see above on policy and naming).
+ *    Check out one of the present unit tests and rename, but beware of
+ *    copy&paste errors!
+ *  -# Add the test to the \b Makefile.am contained in \b unittests.
+ *
+ *  If there is not yet a \b unittests folder:
+ *  -# Create a new \b Makefile.am, check out one of the present ones to get
+ *    an idea, below is a small list of contained elements. Note that the
+ *    variable must begin with a unique name as all Makefile.am on unit tests
+ *    are included into one big Makefile.am in \b src/unittests.
+ *  -# Add your ...SOURCES and ...HEADERS to TESTSOURCES and TESTHEADERS.
+ *  -# Add an include directive to \b src/unittests/Makefile.am of this
+ *    newly created \b Makefile.am.
+ *
+ *  What's contained in the \b Makefile.am:
+ *  -# ...SOURCES and ...HEADERS gathering all source and header files in this
+ *    \b unittests folder (this is needed for the test program that contains
+ *    all unit test in one executable).
+ *  -# ...TESTS gathering all test programs in this \b unittests folder.
+ *  -# ...TESTS is added to TESTS, check_PROGRAMS, noinst_PROGRAMS such that
+ *    it is known that they are just tests, programs for \a make \a check and
+ *    are not to be installed.
+ *  -# ...LIBS gathers general libs that all of the tests in this \b unittests
+ *    folder share.
+ *  -# for each unit test:
+ *    -# ...SOURCES gathers all source files that are required for the test.
+ *    -# ...LDADD gathers all libs that are required for compilation.
+ *
+ *
+ * \date 2011-10-31
+ *
  */
