Unit Tests and function calling
Hi, Just wanted a second opinion on how best to handle calling functions which invoke BOOST_REQUIRE and BOOST_CHECK type logic. For example, if I have a test like: void stuff( ... ) { BOOST_REQUIRE( ... ); BOOST_CHECK( ... ); } BOOST_AUTO_TEST( check_stuff ) { stuff( case1 ); stuff( case2 ); stuff( case3 ); } in the CLF log case at least, I only see which lines in stuff failed, but not which which case. I can change things so that we have: bool stuff( ... ) { bool result = true; if ( ( result = require-predicate ) == true ) result = check-predicate; return result; } BOOST_AUTO_TEST( check_stuff ) { BOOST_CHECK( stuff( case1 ) ); BOOST_CHECK( stuff( case2 ) ); BOOST_CHECK( stuff( case3 ) ); } but then I lose the info in the logs over which predicates are failing and it's generally a bit nasty :). As a result, I've been playing with this which seems to encapsulate things pretty well for me (though may introduce more parenthesis than is strictly necessary and may introduce shadowed variables and other issues?): #define BOOL_CHECK( result, pred ) { bool pred_result; BOOST_CHECK( pred_result = ( pred ) ); result = pred_result && result; } #define BOOL_REQUIRE( pred ) { bool pred_result; BOOST_CHECK( pred_result = ( pred ) ); if ( !pred_result ) return pred_result; } #define BOOL_REQUIRE_EQUAL( name, value ) { bool pred_result; BOOST_CHECK( pred_result = ( ( name ) == ( value ) ) ); if ( !pred_result ) return pred_result; } void stuff( ... ) { bool result = true; BOOL_REQUIRE( ... ); BOOL_CHECK( result, ... ); return result; } BOOST_AUTO_TEST( check_stuff ) { BOOST_CHECK( stuff( case1 ) ); BOOST_CHECK( stuff( case2 ) ); BOOST_CHECK( stuff( case3 ) ); } when one of the predicates fails, I get 2 errors in the log - the first being the specific line in 'stuff' and the second being failing case. I've only tested it with g++ and don't know if it's a sensible approach - wondered if any of you guys had any suggestions? Cheers, Charlie
Charles Yates <charles.yates <at> gmail.com> writes:
Hi, Just wanted a second opinion on how best to handle calling functions which
invoke BOOST_REQUIRE and BOOST_CHECK type logic.
For example, if I have a test like:
void stuff( ... ) { BOOST_REQUIRE( ... ); BOOST_CHECK( ... ); }
BOOST_AUTO_TEST( check_stuff ) { stuff( case1 ); stuff( case2 );
stuff( case3 );
}
in the CLF log case at least, I only see which lines in stuff failed, but not which which case.
There is not much you can do in release version of Boost.Test (well you can add some print statement in staff indicating which case is being tested). In new Boost.Test there are new tools to help with specifically this problem: BOOST_TEST_INFO, BOOST_TEST_CONTEXT. These would provide a context information in case of failures, allowing you to see where specifically you failed. Gennadiy
On 2 February 2014 21:30, Gennadiy Rozental <rogeeff@gmail.com> wrote:
In new Boost.Test there are new tools to help with specifically this problem: BOOST_TEST_INFO, BOOST_TEST_CONTEXT.
These would provide a context information in case of failures, allowing you to see where specifically you failed.
Ah - that's good to know :) - unfortunately, I don't think we're in a position to upgrade boost in the short term (since it takes quite a bit of coordination between differing departments and systems). Any major issues with the approach I've taken for boost 1.46? Cheers, Charlie
[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code <CANO4BK-7KsF+siUdw6jr4JvQNSfrQ5hfWY7bO7e2TMZrXHDMSA@mail.gmail.com> thusly:
Just wanted a second opinion on how best to handle calling functions which invoke BOOST_REQUIRE and BOOST_CHECK type logic.
For example, if I have a test like:
void stuff( ... ) { BOOST_REQUIRE( ... ); BOOST_CHECK( ... ); }
BOOST_AUTO_TEST( check_stuff ) { stuff( case1 ); stuff( case2 ); stuff( case3 ); }
in the CLF log case at least, I only see which lines in stuff failed, but not which which case.
I can change things so that we have:
bool stuff( ... ) { bool result = true; if ( ( result = require-predicate ) == true ) result = check-predicate; return result; }
BOOST_AUTO_TEST( check_stuff ) { BOOST_CHECK( stuff( case1 ) ); BOOST_CHECK( stuff( case2 ) ); BOOST_CHECK( stuff( case3 ) ); }
but then I lose the info in the logs over which predicates are failing and it's generally a bit nasty :).
Use the 2nd form of the code you have posted and have your custom predicate return boost::test_tools::predicate_result instead of bool. Then you can build as an elaborate failure message as you need in order to understand the cause of a failing test case. You get the benefits of a custom predicate, proper reporting of the failure location in the test case, and a useful diagnostic message when it fails. See these pages: <http://user.xmission.com/~legalize/tmp/boost.test/libs/test/doc/html/test/reference/test_classes/predicate_result.html> <http://user.xmission.com/~legalize/tmp/boost.test/libs/test/doc/html/test/reference/assertion/boost_level_message.html> You have been able to do this for a long time, but it was never properly documented and I don't know why the maintainer of Boost.Test never mentions it when these questions about custom assertions come up. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
participants (1)
-
Charles Yates -
Gennadiy Rozental -
legalize+jeeves＠mail.xmission.com