Re: [boost] Review: Boost Test Library

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