As described in CLOV-39, we are using Clover history reports as a way to stop coverage from slipping. In particular, we look at the movers to see what problems have been introduced in the last day, week or month.

I just realized today that what I want in the report is the classes that have caused the biggest slip in coverage. The movers currently are defined as being the classes with the biggest percentage increase or decrease in their own coverage, but this means that small classes can get big increases without adding much impact to the overall coverage. For example, I added a toString method to a really simple class, and its coverage dropped 42%. While it is true that this was something I shouldn't have done, the overall impact to our coverage level is miniscule. All that it has added is a couple of extra lines of uncovered code, but yet it jumps to the top of the list.

I was wondering if we could have some controls over how the movers reports are calculated. I can understand that some users might prefer the current behavior so I don't suggest removing it, but it seems like it would be useful to be able to say how 'movers' is defined: changes in lines covered, changes in methods covered, changes in class percentage etc.

Also, we would very much like the option to be able to include multiple movers reports in one report. Currently each history report can only have one movers section. However, we often want to see it in different ways: movers since the last run, movers this week, movers this month etc. We worked around this by generating the report three times, but that isn't very easy to navigate around. It would be great to have a navigatable history that you could browse through dynamically, but just statically generating multiple reports would be a big step forward. I haven't tried Clover 2 reports yet, so apologies if this is already supported.