Re: [boost] [Release 1.34] Supported Compilers - another view

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-02 08:39:23

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

>> Yes.  What do you get from those macros that's very useful beyond what
>> BOOST_ASSERT supplies?  I really want to know.  Some people I'll be
>> consulting with next week want to know about testing procedures for
>> C++, and if there's a reason to recommend Boost.Test, I'd like to do
>> that.
>
> So you choose to use BOOST_ASSERT. That essentially means that you couldn't 
> have more than one failure.  

Usually my presumption is that if an assert fails, I can't really have
confidence in anything thereafter anyway.

> Now believe it or not there exist the whole 
> different testing culture where people starts with *all* of their assertions 
> failing. And then they are working to "fix" them all. And it's not that rare 
> (at best - nowdays TDD is getting widely spread).

Hmm.  So you might want to start fixing them without starting from the
first one?

>   The Test Tools provide wide variety of "check" different from trivial 
> assert. Their primary advantage is they provide as much information as 
> possible in case of failure. With assert based testing you bound to invoke 
> the debugger in 90% of case if detected failures and only in 10% it's clear 
> from output what is going on. With more smart tools you could deduce error 
> cause without debugging in 90% and only 10% require more detailed excurtion 
> inside test module. Also BOOST_ASSERT is no help when you need to test that 
> particular expression does emit some exception.

True.  I do that in my Python tests all the time, but Python is better
at that than native C++ is.

>    The Execution Monitor helps by catching all errors and reporting them in 
> similar manner. If BOOST_ASSERT( expr ) emit unexpected exception. you have 
> no choice but dig into your program to see what is going on. With Execution 
> Monitor there is bog chance that an exception gets detected and reported 
> automatically. You don't like that it's catching fatal system erros either. 
> But with Unit Test framework it's easily configurable.
>    Another topic is test organization. Boost.Test allows to build complex 
> complex test trees. 

Why is that good?  At some point doesn't it make sense to write a
separate test program?

> In addition it's automate task of testing C++ templates 
> for different set of template parameters of parameterized function with 
> different set of runtime arguments.

Really?  I guess there's a lot I haven't seen in the documentation.
Is there a preview of the new docs somewhere?

>    Latest addition is an ability to test exceptions safety (along the line 
> of the work you did) and facility for logged expectation testing (mostly 
> useful for interaction/boundary testing). There is more to it. If you are 
> really interrested check the docs (well better wait till we update them)

Well, I have checked the docs, and didn't see much of it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com