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
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
>to the current state in the actual *.cpp files.
>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 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
If anyone has a serious objection to these names, please let me know before
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk