Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-02-28 11:56:05


I'm getting the Boost Test Library ready for release. Most comments I've
already replied to, but not this one from Jens:

At 10:18 PM 2/13/2001 +0100, Jens Maurer wrote:

>test_tools.hpp includes a definition for main() only if
>BOOST_INCLUDE_MAIN is defined. This seems prudent, but it means that
>the test programs such as test_tools_example.cpp and test_tools_fail*.cpp
>should define it before including the file.
>It seems inappropriate to do so in the compiler.cfg for the
>regression tests.

I don't see why it would be inappropriate to define BOOST_INCLUDE_MAIN in
compiler.cfg. What's your reasoning?

>I'd rather move the test tools to some boost/test/XXX.hpp subdirectory,
>because we expect the addition of unit tests as well. Besides, the
>usage for the test headers is rather specific, so there's no need
>to put it at the same level as e.g. smart pointers.

Done. I've also used the directory structure Jens suggested in his
addendum to John Maddock's directory structure paper.

>The return code in the example of execution_tools.htm needs to be
adjusted
>to the current state in the actual *.cpp files.

Will do.

>Can we have the output formatting in catch_exceptions.hpp separated
>into another static function so that the "****" doesn't repeat too
>often in the source? Nothing fancy, just
> std::string format_exception(const char * name, const char *info);
>where "info" is usually "ex.what()" except for a few special cases.

Done. I changed the function slightly so it handles all of the
output. The code is now easier to read as a result of calling the
function. I put it in boost::detail because (as Ed Brey pointed out) that
is less likely to cause name clashes than relying on static or the unnamed
namespace in a header or pseudo-header file.

>test_tools.htm: I like the CRITICAL part suggested in another mail
>instead of the _ASSERT suffix. I think the _CRITICAL suffix is more
>logical than putting it in between somewhere.

Agreed. I've cut the macro names down to:

   BOOST_TEST(exp)
   BOOST_TEST_CRITICAL(exp)
   BOOST_TEST_ERROR(msg)
   BOOST_TEST_ERROR_CRITICAL(msg)

BOOST_TEST seems to me to be as meaningful as BOOST_TEST_VERIFY, yet is a
bit shorter, which is important for this most heavily used macro.

BOOST_TEST_ERROR seemed to relate better to the error reported than
BOOST_TEST_FAILURE.

If anyone has a serious objection to these names, please let me know before
the release.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk