]>
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 | ||
9 | [section:test_cases Test cases] | |
10 | A 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__. | |
12 | Information about the execution is recorded, and a log/report is produced. | |
13 | ||
14 | The test runner should be informed of the test case in order to run it: the test case should be *registered* for its | |
15 | inclusion into the /test tree/. | |
16 | ||
17 | The __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 | ||
24 | The test case have a different *declaration* APIs for each of the above scenarios. Preferred APIs will declare the test case | |
25 | and register it automatically in a test tree without a necessity to perform manual registration. | |
26 | ||
27 | [h4 Manual registration] | |
28 | While automatic registration is preferred test case declaration API, it is also possible to declare tests manually. | |
29 | For this APIs, __UTF__ opted for a least intrusive design based on ['generic callback] approach, which signatures | |
30 | depends on the king of test case being declared. | |
31 | ||
32 | The single test module may mix both automated and manual test case | |
33 | registration. In other words, within the same test module you can have both test cases implemented remotely and | |
34 | registered manually in the test module initialization function and test cases that are registered automatically at | |
35 | implementation point. | |
36 | ||
37 | [caution The design of manual test case declaration API in __UTF__ assumes the test case implementation (test function body) | |
38 | and test case creation/registration points are remote. As a result you may forget to register the test case | |
39 | and it's never going to be executed, even though it's present in test file. ] | |
40 | ||
41 | You need to be sure you exhausted all possible ways to employ automatic registration APIs first before you opt | |
42 | to 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] |