+ boost::execution_aborted
+struct execution_aborted {}; ++
This is trivial default constructible class that is used to report gracefull execution abort.
+
+ struct execution_aborted {}; ++
This is trivial default constructible class that is used to report gracefull execution abort.
+These tools are used to check that supplied + values is small enough. The "smallness" is defined by absolute + value of the tolerance supplied as a second argument. Note that to use these + tools you need to include additional header + floating_point_comparison.hpp. Use these tools with caution. To compare + to values on closeness it's preferable to use BOOST_<level>_CLOSE tools.
+The first parameter is the value to check. The + second parameter is the tolerance .
+int test_main( int, char* [] ) { + double v = -1.23456e-3; + + BOOST_CHECK_SMALL( v, 0.000001 ); + return 0; +}+
test.cpp(4) : error in test_main: absolute value of + v{1.23456e-3} exeeds 1e-06
+This tool is used to validate the predicate value and abort the current - test case processing if it fails.
-If predicate evaluates to true, the tool produces a confirmation - message (note: to manage what messages appear in the test output stream set the proper log level), - in other case it produces an error message in a form "fatal error in <test case name>: - test <predicate> fail" and then abort the current test case processing.
-The only parameter of this tool is the boolean predicate value that gets - validated. This could be any expression that could be evaluated and converted to boolean value. The - expression gets evaluated only once, so it's safe to pass complex expression for validation.
-int test_main( int, char* [] ) { - int i = 3; - BOOST_REQUIRE( i > 5 ); - BOOST_CHECK( i == 6 ); // will never reach this check - - return 0; -}-
test.cpp(3) : fatal error in test_main: test i>5 failed
-This tool is used to validate the supplied predicate and abort the current - test case processing if it fails. This test tool is generic. It allows to validate arbitrary one or - two arity predicate. To validate zero or more then two arity predicate use BOOST_REQUIRE - tool. The advantage of this tool is that shows arguments values in case of predicate failure.
-If predicate evaluates to true, the tool produces a confirmation - message (note: to manage what messages appear in the test output stream set the proper log level), - in other case it produces an error message in a form "error in <test case name>: test <predicate>( - arguments_list ) fail for (arguments values)" and abort the current test case processing.
-int test.cpp( int, char* [] ) { - double fp1 = 1.23456e-10; - double fp2 = 1.23457e-10; - double epsilon = 8.1e-6; - - // check weak closeness - BOOST_REQUIRE_PREDICATE( close_at_tolerance<double>( epsilon, false ), - 2, ( fp1, fp2 ) ); // should pass - - return 0; -} --
-
This tool is used to perform a weak validation - of the predicate. This check failure does not cause the test case to fail, - but only warning message logged in test output stream. Use this tool to - validate aspects less important then correctness: performance, portability, - usability etc.
-If predicate evaluates to true, the tool produces a confirmation - message (note: to manage what messages appear in the test output stream set the proper log level), - in other case it produces a warning message in a form "warning in <test case name>: condition - <predicate> is not satisfied"
-int test_main( int, char* [] ) { - BOOST_WARN( sizeof(int) == sizeof(short) ); - - return 0; -}-
test.cpp(2) : warning in test_main: condition sizeof(int) - == sizeof(short) is not satisfied -
-
Revised: 7 January, 2004
+Revised: 13 July, 2005
| Parameter Name: | +detect memory leaks | +
| Environment variable name: | +BOOST_TEST_DETECT_MEMORY_LEAK | +
| Command line argument name: | +detect_memory_leak | +
| Acceptable Values: | +0 + 1 + integer value > 1 |
+
| Description: | +positive value tells the framework to detect the memory leaks (if any). + Any value greater then 1 in addition is treated as leak allocation number + and setup runtime breakpoint. In other words setting this parameter to + the positive value N greater than 1 causes the framework to set a breakpoint +at Nth memory allocation (don't do that from the command line - only when you + are under debugger). Note: if your test program produce memory leaks + notifications, they are combined with allocation number values you could + use to set a breakpoint. Currently only applies to MS family of compilers | +
Here is the list of all parameters:
| Description: | allows to select the unit test framework log format from the list of - formats supplied by the framework. To specify custom log format use unit_test_log + formats supplied by the framework. To specify custom log format use unit_test_log API. |
Revised: 7 January, 2004
+Revised: 13 July, 2005
| fatal_errors | - report only user or system originated fatal errors (for example, memory access violation) | -
| progress | -- report only progress information: number of run test cases vs. overall number of test - cases | -
| nothing | - does not report any information | @@ -93,7 +88,7 @@ Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at www.boost.org/LICENSE_1_0.txt) -
| Description: | -combines an effest of report_format and log_format parameters. Has more priority than either of them if specified. | +combines an effest of report_format and log_format parameters. Has more priority than either of them if specified. |
Revised: 7 January, 2004
+Revised: 13 July, 2005
+ | Parameter Name: | +random seed for random order of test cases | +
| Environment variable name: | +BOOST_TEST_RANDOM | +
| Command line argument name: | +random | +
| Acceptable Values: | +0 + 1 + integer value > 1 |
+
| Description: | +positive value makes the framework to run the test cases in random + order. Also if this value is greater than 1 it's used as a random seed. + In other case random seed is generated based on current time | +