Index: src/documentation/tests/regression-tests.dox
===================================================================
--- src/documentation/tests/regression-tests.dox	(revision 750cff3758142eb977ca963eb8ede4200620a15e)
+++ src/documentation/tests/regression-tests.dox	(revision 6ffc0b5857c2bdc65abf4dd377e4d6ab72c2dc7b)
@@ -85,4 +85,7 @@
  * \section regressiontest-add Adding a new test
  *
+ *  The basic working is: have a input file, do something with it and compare
+ *  to output file against a stored one.
+ *
  *  \attention Name convention of files and directories, e.g.
  *  \b tests/regression/Parser/Pdb with \b testsuite-parser-pdb-save.at
@@ -110,4 +113,30 @@
  *  testsuite is automatically re-compiled when one of the test files has changed.
  *
+ *  On how to write a testsuite test, we refer you to one of these .at files to get a
+ *  notion and  here to have a reference of the possible autotest commands at hand.
+ *  The scheme is always the same basically:
+ *  \code
+ * AT_SETUP([General test part - description of this testsuite section])
+ * AT_KEYWORDS([<some keywords>,<actionname>,[undo/redo]])
+ * ...
+ * AT_CHECK([this], <return value>, [ignore], [ignore])
+ * AT_CHECK([that], <return value>, [stdout], [stderr])
+ * AT_CHECk([fgrep "test fine" stdout], 0, [ignore], ignore])
+ * ...
+ * AT_CLEANUP #remove all temporary files
+ * \endcode
+ * where <return value> is some number the code returns to indicate everything
+ * worked fine. The global theme is specified only once per .at file, file
+ * AT_SETUP and AT_CLEANUP sort of embrace every specific test that you want to do.
+ * Note that it is required to list the action name under AT_KEYWORDS and also
+ * give undo oder redo as an additional keyword if the undo or redo of the action
+ * is tested. It is advised to give further keywords, e.g. the directory name
+ * giving the general theme of the tests (selection, analysis, ...). Also note
+ * that all keywords are always lower-case!
+ *
+ * Note that testing the undo/redo-functionality of an Action is always placed
+ * into the same test file along with the normal functionality but in different
+ * tests (i.e. undo and redo each have their own AT_SETUP .. AT_CLEANUP wrapping).
+ *
  *
  * \date 2011-10-31
Index: src/documentation/tests/unit-tests.dox
===================================================================
--- src/documentation/tests/unit-tests.dox	(revision 750cff3758142eb977ca963eb8ede4200620a15e)
+++ src/documentation/tests/unit-tests.dox	(revision 6ffc0b5857c2bdc65abf4dd377e4d6ab72c2dc7b)
@@ -75,4 +75,34 @@
  *  -# Add the test to the \b Makefile.am contained in \b unittests.
  *
+ * Writing a new unit test then consists of writing the source and the header
+ * file, where you should guide yourself by the already present files. Naming
+ * convention is usually to suffix the name with UnitTest, e.g.
+ * \b SingletonUnitTest.cpp.
+ *
+ * The test class should be named in a similar manner and has the following
+ * look:
+ * \code
+ * class SingletonTest : public CppUnit::TestFixture
+ * {
+ *   CPPUNIT_TEST_SUITE( SingletonTest );
+ *   CPPUNIT_TEST ( blaTest );
+ *   CPPUNIT_TEST ( blablaTest );
+ *   CPPUNIT_TEST_SUITE_END();
+ *
+ * public:
+ *   void setUp();
+ *   void tearDown();
+ *
+ *   void blaTest();
+ *   void blablaTest();
+ * };
+ * \endcode
+ * It inherits CppUnit::TestFixture and defines it as a TEST_SUITE via the
+ * initial macros which also give the test functions to call. Below the test
+ * functions are defined along with setUp() and tearDown() which embrace the
+ * call of each test function, i.e. which create a common test environment for
+ * each test function, by allocating some memory, setting some stuff and
+ * cleaning up in the end again.
+ *
  *  If there is not yet a \b unittests folder:
  *  -# Create a new \b Makefile.am, check out one of the present ones to get
@@ -98,6 +128,20 @@
  *    -# ...LDADD gathers all libs that are required for compilation.
  *
+ * \section unittest-failures Marking tests as expected to fail
  *
- * \date 2011-10-31
+ * If a unit tests fails for a given commit but this is expected because the
+ * failure is repaired after some other implementation lateron, it is useful
+ * and required to mark the test as expected to fail.
+ *
+ * To do this, add a variable \b XFAIL_TESTS if not present to the Makefile.am
+ * in which the failing unit test is contained as follows
+ * \code
+ *   XFAIL_TESTS = SingletonUnitTest
+ * \endcode
+ * This will mark \b SingletonUnitTest as expected to fail and continue testing
+ * even though the test is not passed.
+ *
+ *
+ * \date 2012-04-12
  *
  */
