
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:874q3kz0am.fsf@boost-consulting.com...
"Robert Ramey" <ramey@rrsd.com> 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