alexgorbatchev

Friday, November 22, 2013

Grails Cobertura Plugin Excludes

After setting up the Cobertura Plugin in my Jenkins-Grails build, I was a little surprised to see my build failing because of low test coverage, since I have unit tests to cover nearly every line of the domain, controller, and service classes.  What I failed to consider is the Cobertura plugin believes anything with a .groovy extension is a source file and should have tests.  This includes database migration scripts (i.e. changelog.groovy), non-standard config files, and other miscellaneous application files with a .groovy extension.  Therefore, to have the Jenkins-Cobertura plugin report and more importantly use accurate metrics in evaluating the quality of the build, you must exclude those files.  The coverage exclusions are based on package, so the easiest way to exclude them is to put all of your 'real' code into packages (which should be done anyway) and exclude all default package 'classes' with the following config block in BuildConfig.groovy

coverage {
    //('*') The Single asterik excludes top-level groovy classes/scripts, such as BootStrap, changelog (Database Migration), ApplicationResources, etc
    exclusions = ['*']

    // Creates xml output that can be parsed in the Jenkins-Cobertura plugin
    xml = true
    
    //Keeps the coverage results from a previous set of unit tests (see: https://github.com/beckje01/grails-code-coverage)
    appendCoverageResults = true
}


On a related note, the Spring-Security-Core plugin generates source code instead of providing it via plugin, but does not create unit test code, so there will be little to no coverage out of the box.  Some may argue that the generated code is tested before being packaged into the plugin.  If you are one, then you could substitute the previous exclusions block with the one below:

    //('**/security/*') Excludes packages from the 'security' package, which
    // is where I put my generated Spring-Security-Core classes
    exclusions = ['*','**/security/*']

I would not recommend this however, because if you feel the need to have security on your application, you should test it.

1 comment: