JaCoCo and Lombok coverage (Annotation based filters)

[geo...@markov.eu]

Hi,

has anyone used Lombok (http://projectlombok.org/) with JaCoCo and found a way to ignore the compile-time generated boilerplate code?

example:

import lombok.Data;
@Date
public class Foo {
private String bar;
private String baz;
}

As is plain to see the example class above has 0 logic, however at compile time lombok will generate for me 2 getters, 2 setters, an all arg and a no arg constructor as well as a toString(), a hashCode() and an equals() method.

If I run JaCoCo I get 100% line coverage and 0% method / complexity / branch coverages. Now I can go ahead and write those tests, but I will be testing lombok, not my code.

Is there a way to annotate the class somehow to avoid this?

Inline comments or other markers will not help here since there is no lines of code to put those around.

I have read https://github.com/jacoco/jacoco/issues/14 and I think cases like this above are a good example why someone might need annotation based filtering along side comment- / instruction-based filtering.

Thanks,
Gesh

[Mirko Friedenhagen]

Hello,

what about putting model classes in a package of their own or mark them in the name as DTO. Then you may exclude them with a pattern.

I do not test beans but the code they interact with, you call the getter at another part of your code. If not, why have a getter at all?

Regards Mirko
--
Sent from my mobile

--
You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Georgi Markov]

There was a concern about the coupling of JaCoCo to the production code if you use custom annotations, but you don't have to. I believe the general purpose @SuppressWarnings (http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/SuppressWarnings.html) is perfect for this case.

I would love to be able to write something like this for classes of the above type:

import lombok.Data;
@Data

@SuppressWarnings({"jacoco.complexity","jacoco.method","jacoco.branch"})

public class Foo {
  private String bar;
  private String baz;
}

And be done with it.

Cheers,

Gesh

[Georgi Markov]

Well that is an oversimplified example.

I do have the beans in a separate package, but they mix generated code with custom business logic code. I do write the tests for the custom logic but would like to avoid having to write the tests for the generated code. In this case I end up with anywhere between 30% and 80% method / branch / complexity coverage for these packages. I want to have 100%.

Now I can remove lombok from my dependencies and write (or let an IDE generate) my getters and equals and other boilerplate methods, but then writing tests for these is tedious and superflous. What logic does a getter method have? Why should I test it?

You said it yourself - you don't test your bean packages. But what if there are a few methods in there that do have some interesting logic that you want to test?

Cheers,

Gesh

[Marc R. Hoffmann]

Hi Gesh,

using exiting annotations like @SuppressWarnings is actually a nice
idea. Unfortunatelly @SuppressWarnings has RetentionPolicy.SOURCE which
means it is not available in the compiled class files. The current
architecture of JaCoCo is fully based on class files.

We have a list of ideas for filtering:
https://github.com/jacoco/jacoco/wiki/FilteringOptions

BTW, if Lombok would flag the generated methods as synthetic JaCoCo
would be filter them from the reports.

Best regards,
-marc

[Gesh]

Thanks Marc. That seems like a reasonable change request for project lombok.

I will ask the developer of lombok if they are willing to implement this and keep this post here updated.

Cheers,

Gesh

[dodt...@gmail.com]

Followed this back from the corresponding lombok post. it seems synthetic was ruled out as it would eliminate the generated methods from code completion.

Reinier Zeitserloot:
'How would I mark a method as "JAVA.SYNTHMETH "?

If this means : mark the method as synthetic, then no can do. Those methods are not shown in auto complete and calls to them aren't even compiled. '

[bogdan.ar...@gmail.com]

as for me that is not the solution,
s.a. jacoco is just a metric. But in the project we have another metric: number of @Suppresswarnings per 1000 lines of code.

So if I'd fix jacoco metric with suppresswarning, my team overall key indicator will be still low.

Moving entities out to a specific package even so seems ok in general, in fact is difficult, s.a. project has too many of them, sometimes with conflicting names.

[hon...@amazon.com]

lombok now has option to add @javax.annotation.Generated on all generated code (https://code.google.com/p/projectlombok/issues/detail?id=623). Perhaps an option to suppress coverage base on that annotation?

[Marc R. Hoffmann]

Hi,

@Generated has retention source:

https://docs.oracle.com/javase/6/docs/api/javax/annotation/Generated.html

JaCoCo dos not parse Java sources it is based on class files only.

Regards,
-marc