Index: src/documentation/tests/code-tests.dox
===================================================================
--- src/documentation/tests/code-tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
+++ src/documentation/tests/code-tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
@@ -0,0 +1,47 @@
+/*
+ * Project: MoleCuilder
+ * Description: creates and alters molecular systems
+ * Copyright (C)  2010 University of Bonn. All rights reserved.
+ * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
+ */
+
+/**
+ * \file code-tests.dox
+ *
+ * Created on: Oct 28, 2011
+ *    Author: heber
+ */
+
+
+/**
+ * \page codetest "Code tests"
+ *
+ * Code tests enforce certain principles which the programmer must follow.
+ *
+ * At this moment these are:
+ * -# Every .cpp files must include \b config.h and \b CodePatterns/MemDebug.hpp
+ * -# Every .hpp files must include \b config.h
+ *
+ * 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.
+ *
+ * \section Directory structure
+ *
+ * The code tests are contained in \b tests/CodeChecks. Therein are all test
+ * scripts gathered that use autotest (http://www.gnu.org/s/hello/manual/autoconf/Using-Autotest.html#Using-Autotest).
+ * Mostly, these look through files
+ *
+ * \section Launching all tests
+ *
+ *  TODO: Documentation - explain how to launch all code tests.
+ *
+ * \section Launching some tests
+ *
+ *  TODO: Documentation - explain how to launch some code tests
+ *
+ * \section Inspecting results
+ *
+ *  TODO: Documentation - explain how to inspect code test results.
+ *
+ */
Index: src/documentation/tests/regression-tests.dox
===================================================================
--- src/documentation/tests/regression-tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
+++ src/documentation/tests/regression-tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
@@ -0,0 +1,97 @@
+/*
+ * Project: MoleCuilder
+ * Description: creates and alters molecular systems
+ * Copyright (C)  2010 University of Bonn. All rights reserved.
+ * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
+ */
+
+/**
+ * \file regression-tests.dox
+ *
+ * This file contains explanation how to write, launch and use regression tests.
+ *
+ * Created on: Oct 11, 2011
+ *    Author: heber
+ */
+
+
+/**
+ * \page regressiontest "Regression tests"
+ *
+ * Regression test with this project are used to check on the functionality of
+ * all Actions. The launch the MoleCuilder from the command line with a given
+ * action and option and basically diff the output against a stored file with
+ * the desired result. This should be the behavior of more than 90% of all
+ * regression tests.
+ *
+ * \section Directory structure
+ *
+ * They are contained in the source folder \b tests/regression. There are
+ * categories containing a distinct folder for each action. The folder for the
+ * test of a specific Action has the following structure:
+ *  \li a folder \b pre contains all files required as input to the test.
+ *  \li a folder \b post contains all output files against which we compare all
+ *  or a number of resulting files.
+ *  \li a test script \b testsuite-....at which is included in a similarly-
+ *  named test script one directory level higher.
+ *
+ *  \section Adding a new test
+ *
+ *  Adding a new regression tests consists of the following items:
+ *  -# Create a new folder in a matching category
+ *  -# Create therein subfolders \b pre and \b post
+ *  -# Create a test script where the name begins with \b testsuite- and contains
+ *  category and the action token. See other test scripts to get an idea on how
+ *  to write these and also look here (http://www.gnu.org/s/hello/manual/autoconf/Using-Autotest.html#Using-Autotest).
+ *  -# In the command \a AT_KEYWORD which must be present you should given the
+ *  token of the Action as it would be called from the command line (see below for
+ *  the reason).
+ *  -# Include your testscript in the one present one directory-level up.
+ *  -# Also include your script in \b tests/scripts/Makefile.am such that the
+ *  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).
+ *
+ */
Index: src/documentation/tests/tests.dox
===================================================================
--- src/documentation/tests/tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
+++ src/documentation/tests/tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
@@ -0,0 +1,62 @@
+/*
+ * Project: MoleCuilder
+ * Description: creates and alters molecular systems
+ * Copyright (C)  2010 University of Bonn. All rights reserved.
+ * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
+ */
+
+/**
+ * \file tests.dox
+ *
+ * Created on: Oct 28, 2011
+ *    Author: heber
+ */
+
+/**
+ * \page tests Automated Tests
+ *
+ * There are two kinds of tests:
+ *
+ *  \li \subpage codetest "Code tests"
+ *  \li \subpage regressiontest "Regression tests"
+ *  \li \subpage unittest "Unit test"
+ *
+ * These behave more or less like top-down and bottom-up approaches to automated
+ * 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.
+ *
+ * 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.
+ *
+ * Regression test (http://en.wikipedia.org/wiki/Regression_testing) on the other
+ * hand test some specific functionality of the code from the top-most scope,
+ * i.e. they are integration test that check whether the code eventually does
+ * what's wanted. Lateron, they also check whether added or altered functionality
+ * has not changed the outcome of older functions.
+ *
+ * Note that all tests can be launched via
+ * \code make check \endcode
+ * in the top build directory.
+ *
+ * \section Policy on launching tests
+ *
+ * Note that the above run of \e all \e tests \e should \e pass for each and
+ * every single test for each and every single commit in the code history before
+ * it is pushed to the central repository (git has ample means via \a rebase for
+ * correcting later found errors).
+ *
+ * Before a version tag is given (e.g. v1.1.3) it is to be made sure that also
+ * \code make distcheck \endcode
+ * runs fine and produces a distributable archive.
+ *
+ */
Index: src/documentation/tests/unit-tests.dox
===================================================================
--- src/documentation/tests/unit-tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
+++ src/documentation/tests/unit-tests.dox	(revision 19bc7497091ba44d7d2c52ee7ba0f5997f9f291e)
@@ -0,0 +1,63 @@
+/*
+ * Project: MoleCuilder
+ * Description: creates and alters molecular systems
+ * Copyright (C)  2010 University of Bonn. All rights reserved.
+ * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
+ */
+
+/**
+ * \file unit-tests.dox
+ *
+ * Created on: Oct 28, 2011
+ *    Author: heber
+ */
+
+/**
+ * \page unittest "Unit test"
+ *
+ * Unit tests are done via the CppUnit framework (http://cppunit.sourceforge.net/doc/1.8.0/).
+ *
+ * \section Directory structure
+ *
+ *  Unit tests are always located in a subfolder \b unittests of the component
+ *  that they test, e.g. if checking one of the Parsers, then its unit test
+ *  resides in \b src/Parser/unittests.
+ *
+ * \section Adding new tests
+ *
+ *  TODO: Documentation - explain how to add tests.
+ *
+ * \section Launching all tests
+ *
+ *  All unit tests can be launched as follows:
+ *  -# Enter the build directory
+ *  -# Enter \b src/unittests
+ *  -# Run
+ *  \code make check
+ *  \endcode
+ *
+ * This will run all present unit tests one after the other.
+ *
+ * \section Launching some tests
+ *
+ *  If only some of the tests should be checked, then they have to be launched by
+ *  hand via entering the same directory as in the section before and e.g.
+ *  \code
+ *  ./AnalysisBondsUnitTest
+ *  \endcode
+ *  Note that to allow for debugging of the unit tests, one has to prepend the
+ *  executable as follows:
+ *  \code
+ *  libtool --mode=execute gdb --args ./AnalysisBondsUnitTest
+ *  \endcode
+ *  As we use libtool to take care of shared libraries the executables in
+ *  \b src/unittests are just scripts. The true executables hide in another
+ *  subfolder \b .libs. The scripts set environment variables such that shared
+ *  libraries, which have not been installed so far, are found.
+ *
+ * \section Inspecting results
+ *
+ *  Results of the test are shown during run. An \a Ok(2) indicates that
+ *  two tests for the single launched testsuite passed.
+ *
+ */
