Tag Archives: codenarc

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 {
  helper.foo()
}

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…

Advertisements

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]