Thank you for making this suggestion. Currently, the movers report will only display classes which are included in at least two of the previous history points.
The idea of making an introduced class having coverage of 100% and working from there is a good one.
ie. if a class is introduced with 0% coverage, it will appear as a downward mover by -100%.

The second suggestion you have is similar to something we have considered - ratchetting up of test coverage. This would be at the project level, and would potentially cause a build to fail (similar to the clover-check task) if the latest coverage is less than the previous coverage.

I'll see if I can plan at least the first of these suggestions to be implemented soon, as I think it would be really handy too.

Cheers,
Nick

http://www.cenqua.com/forums/thread.jspa?messageID=12646&#12646

I wouldn't like it, if the base for new files was 100%, because in some of our projects we are far away from 80% or whatever and that would be very disappointing for developers to see -40% (where I'm quite happy when they reached +60% in legacy projects with a hell of smelling code where the average is 20% ).

If there'd be just an option to specify the treshould that'd be great. So then the movers are really helpfull, because they motivate to be above the minimum treshold (because your new class is listed in the movers with +x%) and keep people from falling below the treshold (because there are listed with negative amount in the movers).

Note that this threshould should be different from the miminum coverage that can make a build fail.
I'd be nice to specify a 'minimum coverage' and 'target coverage' seperately.

I could live as well with an option to automatically take the previous average coverage as 'default target coverage' for new classes.
This would make it easier to administer different projects because I didn't have to make different configurations for each team.

Recently I came up with a simpler solution - instead of thinking how to integrate it in the movers report (and what 'old' coverage should be considered if there are new classes) - why not just have a second report-part called:
'Top x New Files'. (Or 'Top x new Files with least coverage') and remove the new files from the movers completely.

I think the use-cases we think of (i.e. 'find bad new classes'' or 'honor good new classes') could be solved with such a simple chart as well.

Later on it could be thought again, what the best way was to integrate new files into the movers (which gets more complicated to do it 'right', I have to admit).
Anyway - since reports can be configured easily both simple - and later sophisticated - solutions don't come into each others way.

Excellent idea! I wish you'd mentioned it earlier
I am going to schedule this for a minor point release before we release Clover 2.3 as it is very doable and will indeed be very useful.

Cheers,
Nick