Dear Peter

> The unit tests will be good only if they are covering all the           > scenarios where the class solves its problems…
The intent  is to look at the code from various angles and keep adding tests.. So you cover most of the code… The compiler will help us keep this documentation in sync.
gcov/tcov would help here ( I was planning to do some of this work — run our test suite through gcov ).

— cheerio atul
Peter Dimov wrote:

Hello, Anders!

Thank you for your comments! I thought you might want to join the discussion ;-).

What you are suggesting is pretty much along the same lines as what I mean… I guess I haven’t expressed myself clear enough, or maybe the scale is different. I don’t want to measure how well developers are performing. On the one hand, my intent is for developers to be able to easily choose a class to work on. On the other hand, I’d like to have a measure for the maturity and quality level of the software. What I’m thinking about is to have for example the following Class Maturity Levels (higher maturity, higher quality): Infancy, Prototyping, Production and Support. I have already written down some thoughts about these but wanted to get some unbiased ideas on the topic before publishing them ;-).

I don’t think that it would be such a huge overhead for any developer to measure maturity level of a class they are working on anyway. What we need is a common evaluation framework for non-functional properties like quality. We all want to create high quality software but how do we measure the quality of our work? Peer review is surely one way to do that but the results of the resulting evaluations need to be communicated with future developers.

Writing unit tests for each class is also quite some overhead but we do it because we think it’s worth it! Writing documentation is also an overhead, but if done right it is at least just as good as unit tests are. What we don’t have now is the ability to say that the class is documented well or that the tests are fine… because we can’t measure these. In the framework, which I have in mind, the documentation will be good only if it describes what problems the class is solving (think of these as requirements for the class, but I’d rather not call them that way) and how they are solved (think of that as specification, not implementation). The unit tests will be good only if they are covering all the scenarios where the class solves its problems…

I hope to get some further comments from you ;-)

Regards,

Peter

anders44 wrote:IMHO I think that adding this mark thing for each class doesn’t add value to programmers. Instead it sounds like a way for some manager to take a look and get some virtual numbers on how “well” the programming is going. By introducing this marking system you are adding quite some overhead.
Instead I think it is better to base the level of completion on how well the module/classes meet the requirements.

This can be measured by doing the tests first and then developing the module/classes until the test is fullfilled. I have had good experiences with this approach.
just my 2c
br/Anders.
…