groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From C├ędric Champeau <cedric.champ...@gmail.com>
Subject Re: Groovy and code coverage
Date Fri, 08 Sep 2017 09:55:09 GMT
I'm not super keen on adding a "feature" like that. First, we already mark
generated methods, thanks to the "synthetic" modifier that fields, methods
and classes can have. Second, either we would have to change the code of
all AST transformations to add this at the relevant places, or
automatically do it. Unfortunately, automatic is not possible, because it
is very well possible for an AST transformation to generate code which is
_actually found in the sources_ (duplicate AST, rename a method, ...).

Last, strictly speaking I don't see why we wouldn't count invokeMethod and
friends into coverage. They _effectively_ participate in coverage.

2017-09-08 11:41 GMT+02:00 Andres Almiray <aalmiray@gmail.com>:

> Hello everyone,
>
> As you may be aware there are only a few choices in the Java pace that can
> be used for code coverage, JaCoCo being the one that gives the most
> accurate results. While it's easy to setup JaCoco for Groovy sources there
> are times where the tool reports no coverage for some lines of code that
> should not have been counted for coverage in the first case, these are some
> of the methods coming from GroovyObject and AST transformations,
> specifically `getProperty`, `setProperty`, `getMetaClass`, and
> `invokeMethod`.
>
> I had a chat with Marc Hoffmann yesterday about this situation, which is a
> topic we've discussed a few times in the past. I've got some good news,
> Groovy is not alone in this problem, the Lombok project has suffered the
> same fate which has prompted them to seek a solution. The alternative they
> came up with is to have Lombok identified generated code that should not be
> covered with a special annotation (@lombok.Generated), JaCoCo has a
> filtering feature (not yet public) that can identify elements annotated
> with said annotation and skip them from coverage reports. See
>
> https://projectlombok.org/api/index.html?lombok/Generated.html
> https://github.com/jacoco/jacoco/pull/513
> https://github.com/jacoco/jacoco/blob/master/org.jacoco.
> core/src/org/jacoco/core/internal/analysis/filter/
> LombokGeneratedFilter.java
>
> This feature will be available for consumption in the next releases of
> Lombok (1.16.8+) and JaCoCo (0.7.9+).
>
> Given this, Marc suggested that Groovy could follow the same idea and
> provide an annotation that JaCoCo can identify, say for example
> @groovy.transform.Generated.
>
> If such annotation were to be added to Groovy we would need (at least) the
> following steps too:
>  - update compiler to annotate `getProperty`, `setProperty`,
> `getMetaClass`, and `invokeMethod` when the class does not explicitly
> defines any of those methods.
>  - review and update all core AST xforms that generate methods that should
> be skipped from coverage.
>  - document the usage of this annotation and encourage AST xform
> developers to use it once they upgrade.
>
> Would be great to have this feature in the 2.6.0 release if possible.
>
> Thoughts?
>
> -------------------------------------------
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>

Mime
View raw message