Boost logo

Boost :

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

"Robert Ramey" <ramey_at_[hidden]> writes:

> David Abrahams wrote:
>> "Robert Ramey" <ramey_at_[hidden]> writes:
>> In my experience, Boost.Test is
>> overpowered for the purposes of Boost regression testing,
> Now that is an interesting observation that I would tend to agree with.
> It really points to the design of boost test itself. I understand the
> the problem - library development gets driven be feature comparisons
> with other libraries, wish lists, "cool" features, and I think more
> mundane aspects like a good "user directed" manual, conceptual
> transparency, idiot-proofness etc seem to lose importance.
> Actually, maybe my concerns can be addressed by going back
> into boost test and using the "minimal" option.

That might help, but the author is opposed to adding the facilities
needed to make that viable for me. I can't turn off the crash
handlers on Windows, for example, so debugging a problem in a "minimal
test" application is often prohibitive.

> As I said before, I think that Boost Test could be much, much
> more important than it is in drawing new users to boost. For
> this to happen I would like to see:
> a) an easier to read and use manual
> b) a minimal level implemented as header only so that users
> in need of immediate gratification could get it. This would
> address the user who turns to boost because he's under
> huge pressure to find a bug. Solving someone's problem
> in less than two hours is going to turn anyone into a boost
> booster.
> I realize that the above is my own personal wish list so
> we have a lot of conceptual recursion here.
>> Windows it tends to stand in the way of debugging by "handling"
>> crashes as exceptions rather than invoking JIT or the debugger.
> Hmmm - I don't we want to invoke the debugger in the
> regression tests.

What happens on the testers machine if it runs this program?

     #include <cassert>
     int main() { assert(0); }

If it throws up a dialog and if we have no test monitor to kill it, I
agree that we ought to have something in place to make sure no dialog
comes up. But I was sure the test script *did* start a monitor that
could kill off any hung applications (?)

> I practice I fire up my debugger on any failed
> test and set my VC debugger to trap on any exception - this
> works great for me.

IIRC, you only get to see the program state after the program has
unwound to the exception handler in the test library. That's too

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at