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