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

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-31 16:14:48

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

> "David Abrahams" <dave_at_[hidden]> wrote in message 
> news:874q3kz0am.fsf_at_boost-consulting.com...
>> "Robert Ramey" <ramey_at_[hidden]> writes:
>>
>>> It damn annoying to find that
>>> all my tests suddenly fail on msvc because of a change
>>> in the test system.  Oh I'm sure it was announced somewhere
>>> and I don't care - its annoying none the less.  Now what
>>> am I to do?  Stop supporting msvc? Shouldn't that be my
>>> decision?  Re write my tests to not use boost test?  I don't
>>> want to do that!
>>
>> It might be a good idea anyway.  In my experience, Boost.Test is
>> overpowered for the purposes of Boost regression testing, and on
>> Windows it tends to stand in the way of debugging by "handling"
>> crashes as exceptions rather than invoking JIT or the debugger.
>
> And as we discussed this is just a default that could be easily changed for 
> manual testing (for example by defining environment variable if you tired to 
> pass cla every time).

It's just another thing to remember and manage.  And then I have to
manage linking with the right library, and read the Boost.Test
documentation to figure out which calls and macros to use, etc.  Oh,
and I also have to wait for Boost.Test to build before I can run my
own tests, and if Boost.Test breaks I am stuck.  So there are lots of
little pitfalls for me.

I'm sure Boost.Test is great for some purposes, but why should I use
it when BOOST_ASSERT does everything I need (**)?  It seems like a lot
of little hassles for no particular gain, and I think that's true for
99% of all Boost regression tests.  I'd actually love to be convinced
otherwise, but I've tried to use it, and it hasn't ever been my
experience that it gave me something I couldn't get from
lighter-weight facilities.

It's really important that the barrier to entry for testing be very
low; you want to make sure there are no disincentives.  For me that
means reaching for BOOST_ASSERT and the facilities of
<boost/mpl/assert.hpp> until it is demonstrated that I need more.

(**) I actually need the Windows JIT debugging trick that does
"throw;" inside the structured exception handler, but Boost.Test
doesn't give me that either IIUC.

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