| 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 | */ | 
|---|