"Robert Ramey" <ramey@rrsd.com> writes:
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> 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 late. -- Dave Abrahams Boost Consulting www.boost-consulting.com