/*
 * 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 three 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 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) 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
 * 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.
 *
 * \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 tests-policy Policy on launching tests
 *
 * We have the the following list of checks on every new version:
 *
 * -# make check on every commit between old and new version in history
 *    for both --enable-debug and --disable-debug
 * -# make distcheck on last version (where version is updated)
 * -# make check with --enable-valgrind on last version
 * -# make check on last version with every possible --enable/--disable 
 *    combination (excluding ecut, valgrind)
 * 
 * \subsection tests-policy-check make check
 *
 * Note that the call
 * \code make check \endcode
 * should \e pass for \e each \e and \e every \a single \e 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), both for \a --disable-debug and \a --enable-debug.
 *
 * \subsection tests-policy-distcheck make distcheck
 *
 * 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.
 *
 * \subsection tests-policy-enablevalgrind make check with --enable-valgrind
 *
 * Since v1.4.8 valgrind's memcheck tool runs through as well (on all regression
 * tests) on make check if configure has been executed with
 * \code ./configure .. -enable-valgrind \endcode
 * There are three glitches, namely regression tests 28-30 which load
 * python scripts and cause many \a PyObject_Free and other errors. These are
 * ignored. A python suppression file was tried but to no success.
 *
 * In summary, a valgrind check prior to giving a version tag is to be made
 * starting from this version to prevent memory leaks.
 *
 *
 * \date 2015-07-31
 *
 */