[Geoserver-devel] Overall coverage with cobertura

GeoServer GeoServer Developer
1

Justin,

the community module process requires an overall module unit test coverage of 40% for promotion:
http://docs.geoserver.org/1.7.x/developer/policies/community-modules.html

I can generate lovely and revealing reports with

mvn cobertura:clean cobertura:cobertura

but I do not see any overall module summary for either line or branch coverage. How do you recommend assessing a module against the 40% coverage requirement?

One weakness I notice in the coverage reports is that simple classes that implement giant APIs (e.g. Collection, FeatureCollection) come off poorly because they have many methods that consist entirely of "throw new UnsupportedOperationException();". Is there any way to exclude these from statistics, or are they there to remind us that giant APIs are a code smell?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

2

Hi Ben,

Yeah... there does not seem to be a way to aggregate the results for all packages. The docs for the plug-in are not that great... perhaps there is something.

And yeah, cases such as implementing big apis is problematic. I guess you just have to take that into account when analyzing the results. The 40% bar is a "soft one" imo that should take such things into account. For instance if a module fell at 39% and had a bunch of cases like this i would simply just "let it go", but yeah yeah, you have have to draw a line somewhere.

Maybe we need a better code coverage tool. We could try going back to clover... but it requires a special license, and maintainance of the license. The nice thing about cobertura is it works out of the box.

One thing I have been interested in looking at lately is sonar:

http://sonar.codehaus.org/

Which seems like a nice tool for doing this sort of stuff. No idea what the reports for code coverage look like or what engine it uses internally. Have you looked into it at all? Even looks like there is a hudson plugin available for it.

Ben Caradoc-Davies wrote:

Justin,

the community module process requires an overall module unit test coverage of 40% for promotion:
http://docs.geoserver.org/1.7.x/developer/policies/community-modules.html

I can generate lovely and revealing reports with

mvn cobertura:clean cobertura:cobertura

but I do not see any overall module summary for either line or branch coverage. How do you recommend assessing a module against the 40% coverage requirement?

One weakness I notice in the coverage reports is that simple classes that implement giant APIs (e.g. Collection, FeatureCollection) come off poorly because they have many methods that consist entirely of "throw new UnsupportedOperationException();". Is there any way to exclude these from statistics, or are they there to remind us that giant APIs are a code smell?

Kind regards,

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

Justin Deoliveira wrote:

Maybe we need a better code coverage tool. We could try going back to clover... but it requires a special license, and maintainance of the license.

Which is why we stopped using it.

The nice thing about cobertura is it works out of the box.

I like cobertura. Integration with maven is great; it just works. The reports are very clear and make review of coverage localisation easy. I do not think that overall coverage is a useful metric. In fact, I do not think any metric is useful except as a warning. I am starting to appreciate the value of cobertura in drawing my eye to undercovered code, hot spots in need of attention.

One thing I have been interested in looking at lately is sonar:
http://sonar.codehaus.org/
Which seems like a nice tool for doing this sort of stuff. No idea what the reports for code coverage look like or what engine it uses internally. Have you looked into it at all? Even looks like there is a hudson plugin available for it.

Sorry, I have not used it.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

4

Ben Caradoc-Davies wrote:

I am starting to appreciate the value of cobertura in drawing my eye to undercovered code, hot spots in need of attention.

A brutal TDD practitioner would see the code coloured red by cobertura as code to be deleted. Either cover it, or delete it.

> Justin Deoliveira wrote:

One thing I have been interested in looking at lately is sonar:
http://sonar.codehaus.org/

Sorry, I have not used it.

Looks like it uses cobertura.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia