3b08f3a436
the test suite and master test suite are now part of a more general section about the test tree. The constraints on the tree are now visible on the TOC.
104 lines
5.1 KiB
Plaintext
104 lines
5.1 KiB
Plaintext
[/
|
|
/ Copyright (c) 2003 Boost.Test contributors
|
|
/
|
|
/ Distributed under the Boost Software License, Version 1.0. (See accompanying
|
|
/ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
|
/]
|
|
|
|
[section:section_glossary Glossary]
|
|
|
|
Here is the list of terms used throughout this documentation.
|
|
|
|
[#ref_test_module][h3 Test module]
|
|
This is a single binary that performs the test. Physically a test module consists of one or more test source files,
|
|
which can be built into an executable or a dynamic library. A test module that consists of a single test source
|
|
file is called ['single-file test module]. Otherwise
|
|
it's called ['multi-file test module]. Logically, each test module consists of four parts:
|
|
|
|
# [link test_setup test setup] (or test initialization),
|
|
# [link test_body test body]
|
|
# [link test_cleanup test cleanup]
|
|
# [link test_runner test runner]
|
|
|
|
The test runner part is optional. If a test module is built as
|
|
an executable, the test runner is built-in. If a test module is built as a dynamic library, it is run by an
|
|
[link boost_test.adv_scenarios.external_test_runner external test runner].
|
|
|
|
[warning The test module should have at least one test-case defined, otherwise it is considered as an error.]
|
|
|
|
[#test_body][h3 Test body]
|
|
This is the part of a test module that actually performs the test.
|
|
Logically test body is a collection of [link test_assertion test assertions] wrapped in
|
|
[link test_case test cases], which are organized in a [link ref_test_tree test tree].
|
|
|
|
[#ref_test_tree][h3 Test tree]
|
|
This is a hierarchical structure of [link test_suite test suites] (non-leaf nodes) and
|
|
[link test_case test cases] (leaf nodes). More details can be found [link boost_test.tests_organization here].
|
|
|
|
[#ref_test_unit][h3 Test unit]
|
|
This is a collective name when referred to either a [link test_suite test suite] or
|
|
[link test_case test cases]. See [link boost_test.tests_organization this section] for more details.
|
|
|
|
[#test_assertion][h3 Test assertion]
|
|
This is a single binary condition (binary in a sense that is has two outcomes: pass and fail) checked
|
|
by a test module.
|
|
|
|
There are different schools of thought on how many test assertions a test case should consist of. Two polar
|
|
positions are the one advocated by TDD followers - one assertion per test case; and opposite of this - all test
|
|
assertions within single test case - advocated by those only interested in the first error in a
|
|
test module. The __UTF__ supports both approaches.
|
|
|
|
[#test_case][h3 Test case]
|
|
This is an independently monitored function within a test module that
|
|
consists of one or more test assertions. The term ['independently monitored] in the definition above is
|
|
used to emphasize the fact, that all test cases are monitored independently. An uncaught exception or other normal
|
|
test case execution termination doesn't cause the testing to cease. Instead the error is caught by the test
|
|
case execution monitor, reported by the __UTF__ and testing proceeds to the next test case. Later on you are going
|
|
to see that this is on of the primary reasons to prefer multiple small test cases to a single big test function.
|
|
|
|
|
|
[#test_suite][h3 Test suite]
|
|
This is a container for one or more test cases. The test suite gives you an ability to group
|
|
test cases into a single referable entity. There are various reasons why you may opt to do so, including:
|
|
|
|
* To group test cases per subsystems of the unit being tested.
|
|
* To share test case setup/cleanup code.
|
|
* To run selected group of test cases only.
|
|
* To see test report split by groups of test cases.
|
|
* To skip groups of test cases based on the result of another test unit in a test tree.
|
|
|
|
A test suite can also contain other test suites, thus allowing a hierarchical test tree structure to be formed.
|
|
The __UTF__ requires the test tree to contain at least one test suite with at least one test case. The top level
|
|
test suite - root node of the test tree - is called the master test suite.
|
|
|
|
|
|
|
|
[#test_setup][h3 Test setup]
|
|
This is the part of a test module that is responsible for the test
|
|
preparation. It includes the following operations that take place prior to a start of the test:
|
|
|
|
* The __UTF__ initialization
|
|
* Test tree construction
|
|
* Global test module setup code
|
|
* ['Per test case] setup code, invoked for every test case it's assigned to, is also attributed to the
|
|
test initialization, even though it's executed as a part of the test case.
|
|
|
|
[#test_cleanup][h3 Test cleanup]
|
|
This is the part of test module that is responsible for cleanup operations.
|
|
|
|
[#test_fixture][h3 Test fixture]
|
|
Matching setup and cleanup operations are frequently united into a single entity called test fixture.
|
|
|
|
[#test_runner][h3 Test runner]
|
|
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].
|
|
|
|
[#test_log][h3 Test log]
|
|
This is the record of all events that occur during the testing.
|
|
|
|
[#test_report][h3 Test report]
|
|
This is the report produced by the __UTF__ after the testing is completed, that indicates which test cases/test
|
|
suites passed and which failed.
|
|
|
|
|
|
[endsect] [/ Glossary]
|