| 1 | /*
 | 
|---|
| 2 |  * Project: MoleCuilder
 | 
|---|
| 3 |  * Description: creates and alters molecular systems
 | 
|---|
| 4 |  * Copyright (C)  2010 University of Bonn. All rights reserved.
 | 
|---|
| 5 |  * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
 | 
|---|
| 6 |  */
 | 
|---|
| 7 | 
 | 
|---|
| 8 | /**
 | 
|---|
| 9 |  * \file tests.dox
 | 
|---|
| 10 |  *
 | 
|---|
| 11 |  * Created on: Oct 28, 2011
 | 
|---|
| 12 |  *    Author: heber
 | 
|---|
| 13 |  */
 | 
|---|
| 14 | 
 | 
|---|
| 15 | /**
 | 
|---|
| 16 |  * \page tests Automated Tests
 | 
|---|
| 17 |  *
 | 
|---|
| 18 |  * There are two kinds of tests:
 | 
|---|
| 19 |  *
 | 
|---|
| 20 |  *  \li \subpage codetest "Code tests"
 | 
|---|
| 21 |  *  \li \subpage regressiontest "Regression tests"
 | 
|---|
| 22 |  *  \li \subpage unittest "Unit test"
 | 
|---|
| 23 |  *
 | 
|---|
| 24 |  * These behave more or less like top-down and bottom-up approaches to automated
 | 
|---|
| 25 |  * testing. Tests are regarded here as a kind of contract. The code itself is
 | 
|---|
| 26 |  * just one hand in two hands shaking, the other hand is resembled by the tests
 | 
|---|
| 27 |  * that check whether the code does exactly what it's supposed to do. Without
 | 
|---|
| 28 |  * testing a larger project is impossible because it cannot evolve: The old
 | 
|---|
| 29 |  * addage and compromises grow and grow. With increasing size, a project must be
 | 
|---|
| 30 |  * refactored (http://en.wikipedia.org/wiki/Code_refactoring) such that new code
 | 
|---|
| 31 |  * does not have to wiggle itself around the same old issues that are
 | 
|---|
| 32 |  * inadvertently and unavoidably present from the start. Before one starts
 | 
|---|
| 33 |  * refactoring, it must be assured by some means that the code before and after
 | 
|---|
| 34 |  * behaves the same with respect to its intended functionality. These means are
 | 
|---|
| 35 |  * the tests.
 | 
|---|
| 36 |  *
 | 
|---|
| 37 |  * Unit tests (http://en.wikipedia.org/wiki/Unit_testing) check on single
 | 
|---|
| 38 |  * components (e.g. classes), dependencies of the components on other classes
 | 
|---|
| 39 |  * with the test frame are often just mimicked via so-called stubs (sort of
 | 
|---|
| 40 |  * dummy components that don't calculate or do anything but return an expected
 | 
|---|
| 41 |  * result suitable for this test only, see http://en.wikipedia.org/wiki/Test_stubs).
 | 
|---|
| 42 |  * These test whether a component always behaves as desired.
 | 
|---|
| 43 |  *
 | 
|---|
| 44 |  * Regression test (http://en.wikipedia.org/wiki/Regression_testing) on the other
 | 
|---|
| 45 |  * hand test some specific functionality of the code from the top-most scope,
 | 
|---|
| 46 |  * i.e. they are integration test that check whether the code eventually does
 | 
|---|
| 47 |  * what's wanted. Lateron, they also check whether added or altered functionality
 | 
|---|
| 48 |  * has not changed the outcome of older functions.
 | 
|---|
| 49 |  *
 | 
|---|
| 50 |  * \section tests-launch-all Launching all tests
 | 
|---|
| 51 |  *
 | 
|---|
| 52 |  * Note that all tests can be launched via
 | 
|---|
| 53 |  * \code make check \endcode
 | 
|---|
| 54 |  * in the top build directory.
 | 
|---|
| 55 |  *
 | 
|---|
| 56 |  * \section tests-policy Policy on launching tests
 | 
|---|
| 57 |  *
 | 
|---|
| 58 |  * Note that the above run of \e all \e tests \e should \e pass for each and
 | 
|---|
| 59 |  * every single test for each and every single commit in the code history before
 | 
|---|
| 60 |  * it is pushed to the central repository (git has ample means via \a rebase for
 | 
|---|
| 61 |  * correcting later found errors).
 | 
|---|
| 62 |  *
 | 
|---|
| 63 |  * Before a version tag is given (e.g. v1.1.3) it is to be made sure that also
 | 
|---|
| 64 |  * \code make distcheck \endcode
 | 
|---|
| 65 |  * runs fine and produces a distributable archive.
 | 
|---|
| 66 |  *
 | 
|---|
| 67 |  * \date 2011-10-31
 | 
|---|
| 68 |  *
 | 
|---|
| 69 |  */
 | 
|---|