]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | [/ |
2 | / Copyright (c) 2003 Boost.Test contributors | |
3 | / | |
4 | / Distributed under the Boost Software License, Version 1.0. (See accompanying | |
5 | / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) | |
6 | /] | |
7 | ||
8 | [section:section_glossary Glossary] | |
9 | ||
10 | Here is the list of terms used throughout this documentation. | |
11 | ||
12 | [#ref_test_module][h3 Test module] | |
13 | This is a single binary that performs the test. Physically a test module consists of one or more test source files, | |
14 | which can be built into an executable or a dynamic library. A test module that consists of a single test source | |
15 | file is called ['single-file test module]. Otherwise | |
16 | it's called ['multi-file test module]. Logically, each test module consists of four parts: | |
17 | ||
18 | # [link test_setup test setup] (or test initialization), | |
19 | # [link test_body test body] | |
20 | # [link test_cleanup test cleanup] | |
21 | # [link test_runner test runner] | |
22 | ||
23 | The test runner part is optional. If a test module is built as | |
24 | an executable, the test runner is built-in. If a test module is built as a dynamic library, it is run by an | |
25 | [link boost_test.adv_scenarios.external_test_runner external test runner]. | |
26 | ||
27 | ||
28 | [#test_body][h3 Test body] | |
29 | This is the part of a test module that actually performs the test. | |
30 | Logically test body is a collection of [link test_assertion test assertions] wrapped in | |
31 | [link test_case test cases], which are organized in a [link ref_test_tree test tree]. | |
32 | ||
33 | [#ref_test_tree][h3 Test tree] | |
34 | This is a hierarchical structure of [link test_suite test suites] (non-leaf nodes) and | |
35 | [link test_case test cases] (leaf nodes). More details can be found [link boost_test.tests_organization here]. | |
36 | ||
37 | [#ref_test_unit][h3 Test unit] | |
38 | This is a collective name when referred to either a [link test_suite test suite] or | |
39 | [link test_case test cases]. See [link boost_test.tests_organization this section] for more details. | |
40 | ||
41 | [#test_assertion][h3 Test assertion] | |
42 | This is a single binary condition (binary in a sense that is has two outcomes: pass and fail) checked | |
43 | by a test module. | |
44 | ||
45 | There are different schools of thought on how many test assertions a test case should consist of. Two polar | |
46 | positions are the one advocated by TDD followers - one assertion per test case; and opposite of this - all test | |
47 | assertions within single test case - advocated by those only interested in the first error in a | |
48 | test module. The __UTF__ supports both approaches. | |
49 | ||
50 | [#test_case][h3 Test case] | |
51 | This is an independently monitored function within a test module that | |
52 | consists of one or more test assertions. The term ['independently monitored] in the definition above is | |
53 | used to emphasize the fact, that all test cases are monitored independently. An uncaught exception or other normal | |
54 | test case execution termination doesn't cause the testing to cease. Instead the error is caught by the test | |
55 | case execution monitor, reported by the __UTF__ and testing proceeds to the next test case. Later on you are going | |
56 | to see that this is on of the primary reasons to prefer multiple small test cases to a single big test function. | |
57 | ||
58 | ||
59 | [#test_suite][h3 Test suite] | |
60 | This is a container for one or more test cases. The test suite gives you an ability to group | |
61 | test cases into a single referable entity. There are various reasons why you may opt to do so, including: | |
62 | ||
63 | * To group test cases per subsystems of the unit being tested. | |
64 | * To share test case setup/cleanup code. | |
65 | * To run selected group of test cases only. | |
66 | * To see test report split by groups of test cases. | |
67 | * To skip groups of test cases based on the result of another test unit in a test tree. | |
68 | ||
69 | A test suite can also contain other test suites, thus allowing a hierarchical test tree structure to be formed. | |
70 | The __UTF__ requires the test tree to contain at least one test suite with at least one test case. The top level | |
71 | test suite - root node of the test tree - is called the master test suite. | |
72 | ||
73 | ||
74 | ||
75 | [#test_setup][h3 Test setup] | |
76 | This is the part of a test module that is responsible for the test | |
77 | preparation. It includes the following operations that take place prior to a start of the test: | |
78 | ||
79 | * The __UTF__ initialization | |
80 | * Test tree construction | |
81 | * Global test module setup code | |
82 | * ['Per test case] setup code, invoked for every test case it's assigned to, is also attributed to the | |
83 | test initialization, even though it's executed as a part of the test case. | |
84 | ||
85 | [#test_cleanup][h3 Test cleanup] | |
86 | This is the part of test module that is responsible for cleanup operations. | |
87 | ||
88 | [#test_fixture][h3 Test fixture] | |
89 | Matching setup and cleanup operations are frequently united into a single entity called test fixture. | |
90 | ||
91 | [#test_runner][h3 Test runner] | |
92 | This is an ['orchestrator] or a ['driver] that, given the test tree, ensures the test tree is initialized, tests are executed and necessary reports generated. For more information [link boost_test.adv_scenarios.test_module_runner_overview see here]. | |
93 | ||
94 | [#test_log][h3 Test log] | |
95 | This is the record of all events that occur during the testing. | |
96 | ||
97 | [#test_report][h3 Test report] | |
98 | This is the report produced by the __UTF__ after the testing is completed, that indicates which test cases/test | |
99 | suites passed and which failed. | |
100 | ||
101 | ||
102 | [endsect] [/ Glossary] |