Lombok: Sonar/Jacoco shows @EqualsAndHashCode as untested

Created on 14 Jul 2015  Â·  21Comments  Â·  Source: projectlombok/lombok

_Migrated from Google Code (issue 589)_

Most helpful comment

Not sure if this adds to the conversation, derails it, or sends it into outerspace, but I read something interesting on the Jacoco bug tracker. Jacoco will ignore any fields, methods, or classes marked as Synthetic.

Is lombok able to mark its synthetic fields, methods, or classes as synthetic (or does it already?) Apparently the @Generated annotation is useless to Jacoco since they instrument bytecode directly, not source(?) Here's the related bug and discussion:

https://github.com/jacoco/jacoco/issues/15#issuecomment-198089485

If it is possible to mark Lombokical things as Synthetic, could we have that as an option to toggle in the Lombok configs? Thanks-a-million!

All 21 comments

:bust_in_silhouette: piderman   :clock8: Oct 11, 2013 at 11:37 UTC

What steps will reproduce the problem?

  1. Make a class with a number of fields and @ EqualsAndHashCode or @ Data annotations
  2. Test it through Jacoco but don't call the equals and/or hashcode methods
  3. Upload the test results to Sonar

What is the expected output? What do you see instead?
I expected Jacoco to not care about the generated methods and show the line with the annotation as having no code to test. Certainly this was the case in Lombok 0.12.0, where the line with the annotation would show up as green. Since 1.12.2 it shows up as untested branches (see attachments), I'm guessing from the equals method.

Using Lombok we could test actual functionality instead of the boilerplate code and get the test coverage to 95% and up. With the untested equals methods this dropped to about 50%.

What version of the product are you using? On what operating system?
Lombok 1.12.2, Java 7.

Please provide any additional information below.
Using Jacoco 0.6.3.201306030806, with TestNG 6.8.7 on SonarQube 3.7.1

:bust_in_silhouette: piderman   :clock8: Oct 11, 2013 at 11:37 UTC

:bust_in_silhouette: piderman   :clock8: Oct 11, 2013 at 11:37 UTC

:bust_in_silhouette: piderman   :clock8: Oct 11, 2013 at 11:37 UTC

:bust_in_silhouette: pangalz   :clock8: Oct 16, 2013 at 16:32 UTC

Issue confirmed.

I've the same enviroment (Lombok 1.12.2 + Java 7 + Jacoco + TestNG + SonarQube).

:bust_in_silhouette: r.spilker   :clock8: Nov 20, 2013 at 01:44 UTC

Can you tell me what change triggered this result? I mean, what code do we now generate differently?

:bust_in_silhouette: and.svanberg   :clock8: Feb 28, 2014 at 09:24 UTC

Still happens with 1.12.4 (after upgrading from 0.12.0).

Using Java 7, Jacoco, JUnit, SonarQube.

:bust_in_silhouette: rlogiacco   :clock8: Jun 12, 2014 at 15:49 UTC

The issue is still there after so long... if there is an accepted solution I can help implement it. Would a marking annotation work?

:bust_in_silhouette: fabrice.daugan   :clock8: Jul 18, 2014 at 10:48 UTC

This not a lombok issue.
The generated code needs to be covered by the UTs or ITs as it had been manually written.
Lombok cannot fix that even it combined amount of branches in the generated code is high.

:bust_in_silhouette: pops7003   :clock8: Feb 10, 2015 at 09:53 UTC

@ fabrice:

In that case we would've to test each and every branch of the generated code, which can be very high (more than 200 in on of the case)
Can't there be a way by which lombok can mark them and Jacoco understands not to include marked for code coverage.

:bust_in_silhouette: [email protected]   :clock8: Apr 13, 2015 at 20:51 UTC

Would it be possible to generate a boilerplate test for boilerplate code? Perhaps add a new annotation like:
@ EqualsAndHashCodeTest
that would generate a Junit test for the annotated private member? See https://gist.github.com/rherrmann/2970842

For instance:
@ EqualsAndHashCodeTest
private Point point = new Point(1,2);

Would generate:
@ Test
private void boilerPlateLombokEqualsAndHashCodeTest () {
EqualsTester equalsTester = newInstance( new Point( 1, 2 ) );
equalsTester.assertEqual( new Point( 1, 2 ), new Point( 1, 2 ) );
equalsTester.assertNotEqual( new Point( 1, 2 ), new Point( 3, 4 ) );
}

_End of migration_

Not sure if this adds to the conversation, derails it, or sends it into outerspace, but I read something interesting on the Jacoco bug tracker. Jacoco will ignore any fields, methods, or classes marked as Synthetic.

Is lombok able to mark its synthetic fields, methods, or classes as synthetic (or does it already?) Apparently the @Generated annotation is useless to Jacoco since they instrument bytecode directly, not source(?) Here's the related bug and discussion:

https://github.com/jacoco/jacoco/issues/15#issuecomment-198089485

If it is possible to mark Lombokical things as Synthetic, could we have that as an option to toggle in the Lombok configs? Thanks-a-million!

Has there been any movement on marking the generated sources as Synthetic?

No, we can not mark it as synthetic because the calling code would no longer be able to see those methods/types/etc.

However, we will add to lombok.Generated annotation that _is_ @Retention(RetentionPolicy.CLASS).

This will be part of the next release.

However, we will add to lombok.Generated annotation that is @Retention(RetentionPolicy.CLASS).

What does it change, if the Java documentation says:

If no Retention annotation is present on an annotation type declaration, the retention policy defaults to RetentionPolicy.CLASS.

?

is this issue resolved ? I am still having same issue and it is directly impacting overall coverage. Using Lombok 1.16.14.

@gunjank no, and I think I agree with some of the comments it's more likely to be a JaCoCo issue (referenced above). This is real generated code that does not have coverage.

Do we have a recommended solution to fix this issue?

Use EqualsVerifier to test it.
Easy to use library, will complain a lot but you will also learn a lot.

On Wed, Oct 16, 2019 at 10:46 AM Saadat Rizvi notifications@github.com
wrote:

Do we have a recommended solution to fix this issue?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/624?email_source=notifications&email_token=AABIERLT6VUBW5B72DE75C3QO3IFDA5CNFSM4B7U5WYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLVTKQ#issuecomment-542595498,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABIERLLHFFYVZV5NK2YOBTQO3IFDANCNFSM4B7U5WYA
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

@tr00per clarity.

@gunjank You'll have to ask jacoco, they need to fix this / yes it is fixed, just tell jacoco to ignore any methods that are annotated with @Generated (I don't know if jacoco can do this, in which case, you should tell them to add this functionality. Better yet, tell them to put lombok's Generated on the default list).

Was this page helpful?
0 / 5 - 0 ratings