ae01c8387c
- section about command line argument filtering for template test cases - many typos fixes - remove reference to bjam
69 lines
3.4 KiB
Plaintext
69 lines
3.4 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:test_cases Test cases]
|
|
A test case is a unit of execution that is run by the [link test_runner test runner]. It contains instructions and
|
|
[link boost_test.testing_tools.boost_test_universal_macro assertions], and its execution is monitored by the __UTF__.
|
|
Information about the execution is recorded, and a log/report is produced.
|
|
|
|
The test runner should be informed of the test case in order to run it: the test case should be *registered* for its
|
|
inclusion into the /test tree/.
|
|
|
|
The __UTF__ covers the following test case scenarios:
|
|
|
|
* *test cases without parameters*: those are similar to the run of a function in the controlled environment of the test runner.
|
|
* *test cases with parameters*: this usage is intended to run the same function with potentially many different parameters,
|
|
each call with a different parameter being handled by the test runner.
|
|
* *test cases on template*: the scenario is to test the same template implementation against several type.
|
|
|
|
The test case have a different *declaration* APIs for each of the above scenarios. Preferred APIs will declare the test case
|
|
and register it automatically in a test tree without a necessity to perform manual registration.
|
|
|
|
[h4 Manual registration]
|
|
While automatic registration is preferred test case declaration API, it is also possible to declare tests manually.
|
|
For this APIs, __UTF__ opted for a least intrusive design based on ['generic callback] approach, which signatures
|
|
depends on the king of test case being declared.
|
|
|
|
The single test module may mix both automated and manual test case
|
|
registration. In other words, within the same test module you can have both test cases implemented remotely and
|
|
registered manually in the test module initialization function and test cases that are registered automatically at
|
|
implementation point.
|
|
|
|
[caution The design of manual test case declaration API in __UTF__ assumes the test case implementation (test function body)
|
|
and test case creation/registration points are remote. As a result you may forget to register the test case
|
|
and it's never going to be executed, even though it's present in test file. ]
|
|
|
|
You need to be sure you exhausted all possible ways to employ automatic registration APIs first before you opt
|
|
to use manual registration. Specifically:
|
|
|
|
* If you need optionally include/exclude some of the test cases, consider using
|
|
__decorator_enabled__ / __decorator_disabled__ / __decorator_enable_if__ decorators instead
|
|
* If you need to register some parametrized test cases based on some data, consider
|
|
[link boost_test.tests_organization.test_cases.test_case_generation data-driven] test cases instead
|
|
* If you need to specify complicated test unit dependencies, you can use __decorator_depends_on__
|
|
decorator instead
|
|
* if you need to share the logic between the test units consider using
|
|
[link boost_test.tests_organization.fixtures fixtures] instead
|
|
|
|
[/ ############################################# ]
|
|
[include nullary_tests.qbk]
|
|
|
|
[/ ############################################# ]
|
|
[include parametric_test_case_generation.qbk]
|
|
|
|
[/ ############################################# ]
|
|
[include typed_parametrized_tests.qbk]
|
|
|
|
[/ ############################################# ]
|
|
[include unary_tests.qbk]
|
|
|
|
|
|
[endsect] [/ test cases]
|
|
|
|
[/EOF]
|