Category Archives: Code quality

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).

Continue reading

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).

Continue reading

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.

Continue reading

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

The event is kindly hosted by SkillsMatter.

Update: new registration link for the event with SkillsMatter:

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

Code coverage and meaningful unit tests

It always worries me if I spot something like the following in a unit test during a code review:

testSomething {

Whilst this exercises a path through the code base (which helps to appease Cobertura), ensures that no exceptions are thrown and there are no ‘typo’ errors in the Groovy code (e.g. wrong property) it isn’t a valid test. A valid ‘black-box’ test should apply known input and compare the output to the expected output.

Ok, so this problem doesn’t just apply to unit tests – it can happen with automated integration tests or functional tests too. However for the unit test you should use mock collaborators to allow the test to just exercise the ‘unit under test’.

The real underlying problem is that the developer isn’t follow the Test Driven Development process. They’ve taken on board that the “code must have 80% automated unit test coverage” but are going about it in the wrong way. So it’s time for some re-education on why the tests must check the output and why writing the test first helps them think about how the class needs to work. Alternatively go for a behaviour driven approach and make the requirements executable!

Now I wonder if I can quickly write a CodeNarc ruleset to flag any test methods that don’t contain assertions…

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


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

The 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]