]> git.proxmox.com Git - ceph.git/blame - ceph/src/boost/libs/test/doc/test_organization/test_cases.qbk
bump version to 12.2.2-pve1
[ceph.git] / ceph / src / boost / libs / test / doc / test_organization / test_cases.qbk
CommitLineData
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
9[section:test_cases Test cases]
10A test case is a unit of execution that is run by the [link test_runner test runner]. It contains instructions and
11[link boost_test.testing_tools.boost_test_universal_macro assertions], and its execution is monitored by the __UTF__.
12Information about the execution is recorded, and a log/report is produced.
13
14The test runner should be informed of the test case in order to run it: the test case should be *registered* for its
15inclusion into the /test tree/.
16
17The __UTF__ covers the following test case scenarios:
18
19* *test cases without parameters*: those are similar to the run of a function in the controlled environment of the test runner.
20* *test cases with parameters*: this usage is intended to run the same function with potentially many different parameters,
21 each call with a different parameter being handled by the test runner.
22* *test cases on template*: the scenario is to test the same template implementation against several type.
23
24The test case have a different *declaration* APIs for each of the above scenarios. Preferred APIs will declare the test case
25and register it automatically in a test tree without a necessity to perform manual registration.
26
27[h4 Manual registration]
28While automatic registration is preferred test case declaration API, it is also possible to declare tests manually.
29For this APIs, __UTF__ opted for a least intrusive design based on ['generic callback] approach, which signatures
30depends on the king of test case being declared.
31
32The single test module may mix both automated and manual test case
33registration. In other words, within the same test module you can have both test cases implemented remotely and
34registered manually in the test module initialization function and test cases that are registered automatically at
35implementation point.
36
37[caution The design of manual test case declaration API in __UTF__ assumes the test case implementation (test function body)
38and test case creation/registration points are remote. As a result you may forget to register the test case
39and it's never going to be executed, even though it's present in test file. ]
40
41You need to be sure you exhausted all possible ways to employ automatic registration APIs first before you opt
42to use manual registration. Specifically:
43
44* If you need optionally include/exclude some of the test cases, consider using enable/disable/enable_if decorators instead
45* If you need to register some parametrized test cases based on some data, consider data-driven test cases instead
46* If you need to specify complicated test unit dependencies, you can use depends_on decorator instead
47* if you need to share the logic between the test units consider using fixtures instead
48
49[/ ############################################# ]
50[include nullary_tests.qbk]
51
52[/ ############################################# ]
53[include parametric_test_case_generation.qbk]
54
55[/ ############################################# ]
56[include typed_parametrized_tests.qbk]
57
58[/ ############################################# ]
59[include unary_tests.qbk]
60
61
62[endsect] [/ test cases]
63
64[/EOF]