groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andres Almiray <aalmi...@gmail.com>
Subject Re: Groovy and code coverage
Date Fri, 08 Sep 2017 13:04:57 GMT
Unfortunately that annotation is coming in JDK9. We'll need something that
can be used with JDK7
 an upwards.

-------------------------------------------
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.

On Fri, Sep 8, 2017 at 3:00 PM, Remi Forax <forax@univ-mlv.fr> wrote:

> A standard annotation for generated code was added in Java 9:
> http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/
> Generated.html
>
> Rémi
>
> ------------------------------
>
> *De: *"Andres Almiray" <aalmiray@gmail.com>
> *À: *dev@groovy.apache.org
> *Envoyé: *Vendredi 8 Septembre 2017 11:41:18
> *Objet: *Groovy and code coverage
>
> 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