Home | Libraries | People | FAQ | More |
In case you observe a failure in unit tests and you are using a debugger
to determine the cause, it may get really difficult to step into the expression
inside an assertion. Because BOOST_TEST
builds an expression
tree before evaluating it, the "Step Into" function of the debugger
will have to step into every step of building the expression tree before,
you can go into the evaluation of the expression.
In order to mitigate the problem, the test module can be build in the mode
which disables the building of expression trees inside assertions. In this
mode, the first thing the assertion does is to eagerly evaluate the tested
expression. You enable this mode by defining symbol BOOST_TEST_TOOLS_UNDER_DEBUGGER
(either with #define
or
with compiler option -D
)
prior to including any of the Unit Test Framework headers.
Caution | |
---|---|
When the eager evaluation of expressions is turned on, the expressions
are evaluated literally: this automatically disables
any special semantics, like tolerance for floating-point types or |
The inconvenience with BOOST_TEST_TOOLS_UNDER_DEBUGGER
is that you have to recompile the test module. The Unit Test Framework
gives you another option to compile two versions of the assertions and select
the one to be used dynamically depending on whether the test module is run
under debugger or not. This mode is enabled by defining symbol BOOST_TEST_TOOLS_DEBUGGABLE
(either
with #define
or with compiler
option -D
)
prior to the inclusion of any of the Unit Test Framework
headers.
In order to determine if the test module is run under debugger or not, function
boost::debug::under_debugger
is used.
Caution | |
---|---|
At present, function |