"Gennadiy Rozental" <gennadiy.rozental@thomson.com> 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