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