"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
Actually Boost.Test is quite stable for a while now.
It's not a predisposition; it's borne of experience. Every time I try to use the library, thinking it's probably the right thing to do, and wanting to like it, I find myself wondering what I've gained for my investment. Until you can hear that and respond accordingly -- instead of dismissing it as the result of predisposition -- Boost.Test is going to continue to be a losing proposition for me.
I am not quite sure what you want me to hear. How should I enhance the library for you to find it worth your investements.
You could make the minimal facility more usable.
BOOST_CHECK don't; if expression throw an exception you need to start a debugger to figure out what is going on - using Boost.Test in majority of the cases it's clear from test output.
It's hard to imagine what test output could allow me to diagnose the cause of an exception. Normally, the cause is contained in the context (e.g. backtrace, etc.) and that information is lost during exception unwinding.
It depends how you organize you program. My exception classes frquently report failure location along with erro cause. So instead of stepping throw whole stack inside the debugger I jump directly into source code.
The failure location is often not very interesting, and the more encapsulated and highly factored my program gets, the more that's true.
And I think you are seriously mistaken.
That may be so. Maybe you should point me at some Boost regression tests that benefit heavily from Boost.Test so I can get a feeling for how it is used effectively.
Not a partucular test. But in a amoung current test modules under /libs about 200 modules using test tools different from simple BOOST_CHECK/BOOST_ASSERT
Yes, but it's the ones that just use BOOST_CHECK that I claim are not gaining a whole lot from the library.
#define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_CASE( t ) { // here you go: }
Is this a hi barrier?
It depends. Do I have to link with another library? If so, then add the lines of the Jamfile (and Jamfile.v2) to what I need to start with. What about allowing JIT debugging? Will this trap all my failures or can I get it to launch a debugger?
You could use
#include <boost/test/included/unit_test.hpp>
BOOST_AUTO_TEST_CASE( t ) { // here you go: }
No need for linking. Catching system error you could disable in either Jamfile on in environment.
Oh? That's an improvement in convenience, to be sure. Maybe I'll try again. -- Dave Abrahams Boost Consulting www.boost-consulting.com