From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-11-01 11:27:04
"David Abrahams" <dave_at_[hidden]> wrote in message
> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
>>> When using boost/test/minimal.hpp, it doesn't respond to the presence
>>> of --catch_system_errors=no, which makes it unreasonably difficult to
>>> debug problems on Windows. All I get is an exception caught by the
>>> test library, with all of the info about the real cause of the error
>>> lost, which is absolutely unhelpful. It seems to me that the minimal
>>> configuration ought to at least be useful for writing and debugging
>>> simple test cases.
>> Minimal testing facility doesn't process any CLA.
> http://boost.org/libs/test/doc/usage/command_line.html and
> http://boost.org/libs/test/doc/usage/msvc_net.html#t2 don't make that
Minimal testing facility is in many sences "crippled" relative to te rest of
Boost.Test components. There is a separate chapter covering it and the rest
of docs doesn't have anything to do with it. If you think it worth the
effort I could explicetly specify in all places: "Is not applicable ot
Minimal Testing facility"
> BTW, "CLA" is not a universally understood abbreviation.
It's quite frequently used. But I could unabbreviate in docs.
>> Execution monitor by default catches all the errors (which I think
>> reasonable default).
> I'm not sure it is. It seems to me that Boost.Test has two uses:
> 1) for writing effective unit and regression tests
> 2) for writing "resilient" software
> Given its name, I think (1) should be emphasized, but I think the
> "catches all errors" behavior is more appropriate to (2).
I guess it's a matter of personal preferense either. I nmany cases I don't
need core to fix an error anonced with "fatal error" message. And if do need
I could always specify extra parameter. On the other hand regression tests
runners never need this. And I wouldn't want to force them to add this
parameter always. IOW I think we need more compeling reason to change a
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk