[aerogear-dev] How we failed to collect code coverage results with Groovy

Karel Piwko kpiwko at redhat.com
Tue Oct 8 06:57:27 EDT 2013


Hi All,

here are the details of the story:

We have some unit tests written in Java and integration tests written in
Groovy. We collect results using Jacaco in "appending" mode. That means we are
able to run unit tests with instrumented code and integration tests with
instrumented AS JVM. Then we can merge results together or not, depends on what
we want.

So, where are the problems with Groovy compiler? Simply, it generates a
different bytecode than Javac. So, when running integration tests, we are
constructing microdeployments, that contain classes or archives, deploy them to
AS, using what's available on classpath or in Maven repositories (or, Maven
Reactor for multimodule projects). And we actually need those classes to be
compiled by the *same* compiler all the time so jacoco can match results.

So, what are the options?

1/ Use groovyc to compile all the code we need to instrument. However, that
means that we would need to change remote repository to a proxy repository where
binaries are build via groovy and rebuild all aerogear with groovy before code
coverage gathering happens. I did that for the first round of CC results, and
it was simply a too much mess to cope with despite the fact that I skipped
workaround for Maven and thus I got I bit underestimate results.

2/ Use javac everywhere. So, we need to remove groovy.

3/ Use groovyc to compile only tests. This unfortunately does not work, as
maven-compiler-plugin ignores includes/excludes. Tadeas can provide
upstream issue #. Moreover, it takes *years* to get something fixed in Maven.

4/ Migrate to Gradle, where include/exclude might work correctly

So, the option is 2/.

Karel


More information about the aerogear-dev mailing list