Clover continuous inspection

Please forgive this newbie question! I'm looking at setting up Clover as an alternative to Sonar, and I don't seem to be able to tune them in the same way. Sonar seem to examine our entire code base (large!) but I only want to report on recent changes to the code base (known as continuous inspection in Sonar-speak). For example:

what changed in my application over last 30 days or since version x.y.z?

did quality improve during version x.y.z release?

which violations have been created since 1st of January and by who?

how much is new code covered by unit tests?

which projects have increased their technical debt during last 3 months?

Is this possible?

1 answer

1 accepted

Accepted Answer
1 vote

Hi Kev,

Your questions are great!!!

Some of features requested by you require connection to versioning system ("by who", "new code") and Clover does not have such integration. However, the Historical Report feature in Clover can give you some answers. During build you can create a history point - a baseline used later for comparisons.

what changed in my application over last 30 days?

Create history point (e.g. using <clover-historypoint> Ant task) in each build. Configure history section in HTML report section and set that it should compare last 30 days (<clover-report>...<history>...<movers interval="30d">). A report will show you a list of classes for which coverage has changed.

Configure charts in the history section and choose among over 20 available metrics (<clover-report>...<history>...<chart>...<columns>). A report will show you trend on a graph.

... or since version x.y.z?

Similar to above, but don't use interval attribute in <movers> - then Clover will compare last two history points - and provide exactly two history points - from version x.y.z and from current one.

did quality improve during version x.y.z release?

As above. You can create a chart with selected metrics.


which violations have been created since 1st of January and by who?

There is nothing as "violations" in Clover (i.e. like violations from Checkstyle or Findbugs). However, you can set up a <clover-check> task, which will check if total/package code coverage is above defined threshold; and if not - Clover will fail a build.

... "Since 1st of January"

You can check whether code coverage has dropped below certain level (<clover-check historyDir="..." threshold="...">) since last history point (and you can use a history point from certain date, actually).

... "by who"

This information is not available. And as a matter of fact it's not so easy to find a person to blame :) For example, if unit test fails - is it because of bug in application code or because test is incorrect or maybe because of some environment problem?

Probably you'd have to make such integration manually - for example if junits have failed, check repository log who made last commit or commits since last build.

... "how much is new code covered by unit tests?"

This information is not directly available. Again, more questions arise - what do we mean by "new code": completely new class, class which was modified, or maybe source lines which were modified? what if class was just renamed during refactoring? what about new test classes?

What is possible to do is as follows:

- get a list of source files to be checked (e.g. by 'svn log')

- pass this list as nested <files> or <fileset> element in <clover-setup> or <clover-instrument> (probably also add all test classes as well)

Clover will generate report only about these files, which were instrumented.

which projects have increased their technical debt during last 3 months?

It depends on what do you mean by "which project" and "technical debt" and how do you want to measure it. Clover is capable to generate multiple linked HTML reports (<clover-report>). Clover can also store some simple statistics (<clover-log outputProperty="...">). Clover can calculate metrics - also custom ones (<clover-report><current>)

Recommended lecture:

Regards
Marek

Hello Marek,

It seems that I have a problem with the movers. I am using the default reportDescriptor and in the maven debug I can see:

build	03-Jul-2013 04:23:37	[DEBUG] Including history point file: '/data/bamboo-data/xml-data/build-dir/C-SP-JOB1/clover/clover-20130619045909.xml.gz'
build	03-Jul-2013 04:23:37	[DEBUG] Including history point file: '/data/bamboo-data/xml-data/build-dir/C-SP-JOB1/clover/clover-20130703035740.xml.gz'
build	03-Jul-2013 04:23:37	[INFO] Loading historical coverage data from: '/data/bamboo-data/xml-data/build-dir/CLWTESTS-SPCOV-JOB1/clover'
build	03-Jul-2013 04:23:38	[INFO] Read 2 history points.
build	03-Jul-2013 04:23:38	[INFO] movers interval adjusted to 1 week

As you can see, the history points are from 19 Jun and 3rd Jul (as I want to have movers between today compared to 19 Jun). But Clover "adjusts" the interval to 1 week and the report is wrong, showing not enough movers and added classes (but interestingly it is showing the coverage graph with correct dates).

Any idea why this happens?

I even tried to force the interval to be 1 year with <movers /> but anyway then I see in the report:

Top movers over the last 1 year (Actual Interval: 1 week, Range: 5, Threshold: +/-1)

EDIT:

Well, as usually after submitting I found the answer. I had to set <movers range="10000"... and <added range="10000"... to see all the classes. This lacks for me a possibility to set range="0" to show all.

Another issue is that I think that Clover wrongly shows the "interval" because after adding range I can see all the added and movers correctly, but it still shows "1 week" regardless of the history points distance being 2 weeks.

The default report for maven-clover2-plugin has a following definition:

&lt;historical outfile="${historyout}" historydir="${history}" charset="${charset}" title="${title}" titleAnchor="${titleAnchor}" span="${span}"&gt;
  &lt;format refid="clover.format"/&gt;
&lt;/historical&gt;

As you can see, the span parameter is passed here. I suppose that you have the "span" option set to 1 week for clover2:clover goal, am I correct?

If yes, then this can be a reaon why <movers> are being reduced from ~2 weeks to 1 week.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published yesterday in Jira Ops

Jira Ops Early Access Program Update #1: Announcing our next feature and a new integration

Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...

289 views 0 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you