source: src/documentation/tests/tests.dox@ 15c75f8

/*
 * 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
 *
 * 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), both for --disable-debug and --enable-debug.
 *
 * 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.
 *
 * Since v1.4.8 valgrind's memcheck tool runs through as well (on all regression
 * tests). There are three glitches, namely regression tests 28-30 which load
 * python scripts and cause many PyObject_Free and other errors. These are
 * ignored. A python suppression file was tried but to no success.
 * Similarly, a valgrind check prior to giving a version tag is to be made
 * starting from this version to prevent memory leaks.
 *
 *
 * \date 2014-08-29
 *
 */