C.R.A.P. metrics for Grails

This is a quick how-to post on getting Change Risk Anti-Patterns statistics for your Grails code.

Firstly thanks to Jeff Winkler for bringing the new GMetrics v0.5 CrapMetric to my attention and thanks to Chris Mair for his great work on GMetrics (and Codenarc).

What is Change Risk Anti-Patterns?

It is a method to analyze and predict the amount of effort, pain, and time required to maintain an existing body of code. Given a Java method m, C.R.A.P. for m is calculated as follows:
C.R.A.P.(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)
Where comp(m) is the cyclomatic complexity of method m, and cov(m) is the test code coverage provided by automated tests.
For more background information see this blog post describing the C.R.A.P. metric.

Setting up Grails

This is very fresh so you’ll need to do a little bit of tinkering until I can get the following changes incorporated into the GMetrics plugin!
Note you’ll also need to have the Code Coverage plugin installed (refer to “Grails & Hudson Part 3: Testing” for more details on that).

Install the GMetrics plugin

This is the straightforward bit:
grails install-plugin gmetrics

The hackery

With GMetrics plugin version 0.3.1 you’ll need to edit the installed plugin dependencies.groovy (e.g. ~/.grails/1.3.7/projects/foo/plugins/gmetrics-0.3.1/dependencies.groovy) to use gmetrics 0.5 instead of 0.3.
Line 27 should be changed to:

provided('org.gmetrics:GMetrics:0.5') {
}


And you’ll want to modify scripts/gmetrics.groovy to use metricSetFile on the Ant task otherwise it will just use the default metrics which doesn’t include C.R.A.P.
e.g. line 44 should become:

ant.gmetrics(metricSetFile:metricSetFilename)


Define a metric set

We now need to tell GMetrics which metrics to run – out of laziness I saved this in the root of the Grails project as test.gmetrics:

import org.gmetrics.metric.cyclomatic.CyclomaticComplexityMetric

final COBERTURA_FILE = 'file:target/test-reports/cobertura/coverage.xml'

  metricset {
    def cyclomaticComplexityMetric = metric(CyclomaticComplexityMetric)

    def coberturaMetric = CoberturaLineCoverage {
      coberturaFile = COBERTURA_FILE
      functions = ['total']
    }

    CRAP {
      functions = ['total']
      coverageMetric = coberturaMetric
      complexityMetric = cyclomaticComplexityMetric
    }
  }


Configure the plugin

If you want the HTML report, then your Config.groovy will need a single addition to specify the metric set:

gmetrics.metricSetfilename = 'file:test.gmetrics'


If you want an XML report you’ll also need:

gmetrics.outputFile = 'target/test-reports/GMetricsReport.xml'
gmetrics.reportType = 'org.gmetrics.report.XmlReportWriter'


Let’s go

Now it’s all configured, we just need to ensure that we have coverage data before we run the CrapMetric.

e.g.
grails test-app -unit -coverage -xml

We can now run:
grails gmetrics

The report will be generated and the plugin output will state where it has been written to. The CRAPpy threshold has been defined as 30 – so the report will help to highlight the areas of code that you need to concentrate on first.

Remember that over complex code with full test coverage can still be classed as CRAPpy.

Relevancy Driven Development with Solr

The relevancy of search engine results is very subjective so therefore testing the relevancy of queries is also subjective.
One technique that exists in the information retrieval field is the use of judgement lists; an alternative approach discussed here is to follow the Behaviour Driven Development methodology employing user story acceptance criteria – I’ve been calling this Relevancy Driven Development or RDD for short.

I’d like to thank Eric Pugh for a great discussion on search engine testing and for giving me a guest slot in his ‘Better Search Engine Testing‘ talk* at Lucene EuroCon Barcelona 2011 last week to mention RDD. The first iteration of Solr-RDD combines my passion for automated testing with my passion for Groovy by leveraging EasyB (a Groovy BDD testing framework).

Grails & Hudson / Jenkins Part 6: Sonar

Sonar is an open source code quality management tool – this requested addition to the Grails & Hudson / Jenkins series gives a quick run through of how to set up Sonar to analyse Grails code from a Jenkins job.

Grails & Hudson talk at London GGUG

I’ll be presenting Grails & Hudson at the October meet-up of the London Groovy & Grails User Group. The proposal for this talk actually inspired the Grails & Hudson series on this blog – so come along as you may get a sneak preview of some of the content for upcoming posts in the series!

More details here on meetup.com.

The event is kindly hosted by SkillsMatter.

Update: new registration link for the event with SkillsMatter: http://skillsmatter.com/event/java-jee/advanced-grails-ci-testing-stats-deployment-with-hudson/rl-390

Update: If you missed it you can see the podcast.

Grails & Hudson part 1: CodeNarc

Grails has a rich plugin eco-system with over 400 hundred plugins – so it’s easy to miss something useful. If you’re serious about software craftsmanship, then using static code analysis tools should be part of your quality regime as it gives further insight into the code base (and if you insist, yes it’ll help with your Technical Debt management).

CodeNarc provides static code analysis for Groovy and the CodeNarc plugin for Grails allows you to perform this analysis with the “grails codenarc” script. Behind the scenes this uses the CodeNarc ant task and settings from grails-app/conf/Config.groovy and produces an HTML report by default.

Until recently, if you used the codenarc target within a continuous integration server such as Hudson – then the HTML report would be generated and sit in the workspace waiting for a diligent developer to check it. You can imagine how often that happens in practice with all the other demands of a project!

However, I’ve now integrated the CodeNarc XML output with the Hudson Violations plugin so that an overview trend line is shown against the Hudson job. Then the team quickly fixed the violations…

You can also get a breakdown by priority:

And in-context views of the violations so you know what to fix:

This is how you do it…

Grails config.groovy

codenarc {
 reportName = 'target/test-reports/CodeNarcReport.xml'
 reportType = 'xml'
 // any further settings like maxPriority1Violations=0
}

Hudson

Set up your Grails build step – normally you’d add the ‘codenarc’ target:

The codenarc.properties file can be used to configure specific exclusions, the location of this file can be passed in as a system property (shown above).

You need to have version 0.7.7 (or later) of the violations plugin installed (Manage Hudson > Manage Plugins > Available and search for Violations).
As this is a recent addition, I’m using a patched version of the Violations plugin, though the patch has been integrated into trunk (I’ll update when it is released).
Configure violations:

Note the ‘Faux project path’ – you may need to set this to get an in-context view working properly due to path (e.g. if your code is checked out to workspace/trunk)

I also had a contribution to CodeNarc accepted at the weekend to add an inlineXml report type – this will, with a minor tweak to the CodeNarc parser, allow the Hudson Violations plugin to give the rule description on the pop-up message.

[image here]