123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103 |
- [/
- / 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]
|