
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. If its not possible now it should be easy for boost test to be jiggered around so that functionality is of several levels - for example a) minimal - see below b) standard - sufficient facilities for simple regression testing - works on all concievable compilers - LOL c) better - more features - compiler support at descretion of the boost test library author. Would require a table of which features are supported by which compilers. This would be free as the table is already generated by the boost regression testing. d) delux - every bell and whistle ever suggested that the library author wants to implement. 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. 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. Robert Ramey