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
Group of volunteers and me at the moment working on Boost.Test documentation update. If you have any particular requests and/or willing to participate - please let us hear it.
conceptual transparency, idiot-proofness etc seem to lose importance.
You need to be more clear for me to understand what exactly you are "missing"
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 conceivable compilers - LOL
c) better - more features - compiler support at discretion 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.
Essentially the state of affairs is like this already. There is the Minimal Testing Facility component (header only). There is the Unit Test Framework that works on most compilers. And there are new features that ifdefed out for old compilers. But my position is that we need to consciously move away from old compilers to make code base healthier. Requirement for feature compiler support is also scaring. I would really prefer not to do this.
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.
This looks like two contradictory goals: you may not be able to solve someone problem in 2 hour using facility with minimal functionality Gennadiy