Gennadiy Rozental wrote:
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"
This is not a critism of Boost Test but an observation on how things get prioritised in all boost libraries. I thnk that adding the "new features" is more interesting than making a better manual and examples so the latter tends to lag. But to answer your question about what I'm "missing" What I would like to see is: Introduction Tutorials small commented example at narrative Min Test facility Unit Test framwork Program Test ... Implementation. Or maybe Introduction Minimal Test facility Tutorial - commented example and nararative Refererence- Implementation notes, etc UnitTest Framework - includes all the faciltiy of the Minimal Test facility + ? Tutorial - commented example and nararative Implementation notes, etc ? Other stuff Usage advice specific compiler issues etc. ... Basically I would love to copy the the tutorial to my own project and edit it to make my test. That might sound ridiculous - but that's would I would like to be able it do.
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.
I suspected as much but it doesn't jump out from a cursory examination of the manual.
And there are new features that ifdefed out for old compilers.
Which is ok by me.
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.
I'm not sure what this refers to. I would be just happy to know that boost test won't be improved in such a way that it breaks my old stuff that doesn't use the new features.
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
LOL - again I think you're underestimating the impact even a minimal facility can have. Remeber that the usual alternative is to do no unit testing at all. I envision a common situation - (In fact, at this very moment I'm stuck on another project and I find my self in this exact situation). I'm working on my next wizbang project and I'm under huge pressure to fix a bug. I've been working on it for days with no luck. Now I realize that its much deeper than I thought and that it could be anywhere. In desperation I look to boost and find Boost Test. The introduction shows me the joys of unit testing which I havn't been using. I'm really desperate and will try anything that only takes two hours to try. I down load boost headers. Copy the tutorial example from boost test an make a test for one mof my routines. 2 hours. Still havn't found my bug but since I still don't know what to do I repeat the processes for the rest of the program. The bug turns out to be pretty stupid and easy to spot - if I had only thought to look at the right place. I leave the boost test stuff in becuase now its "free". I've been kidnapped into the boost community in spite of myself. Contrast that the current situation. I look into boost test. Well reading the documents is a couple of hours. Then there is bjam and library building and linking. Right away I'm on to something else. Now you can argue that the world shouldn't be like this and maybe your right - but I think that boost test could work as described above - just by making the manual easier to read - so I have high hopes for the new manual. Robert Ramey PS fyi - my current situation is programming a gameboy color to implement a hangglidng flight instrument. This thing is a bitch to program. I could sure use boost test here - any chance of a straight "C" version? RR