...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
Here is the list of terms used throughout this documentation.
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:
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 external test runner.
Warning | |
---|---|
The test module should have at least one test-case defined, otherwise it is considered as an error. |
This is the part of a test module that actually performs the test. Logically test body is a collection of test assertions wrapped in test cases, which are organized in a test tree.
This is a hierarchical structure of test suites (non-leaf nodes) and test cases (leaf nodes). More details can be found here.
This is a collective name when referred to either a test suite or test cases. See this section for more details.
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 Unit Test Framework supports both approaches.
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 Unit Test Framework 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.
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:
A test suite can also contain other test suites, thus allowing a hierarchical test tree structure to be formed. The Unit Test Framework 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.
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:
This is the part of test module that is responsible for cleanup operations.
Matching setup and cleanup operations are frequently united into a single entity called test fixture.
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 see here.
This is the record of all events that occur during the testing.
This is the report produced by the Unit Test Framework after the testing is completed, that indicates which test cases/test suites passed and which failed.