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