code coverage and lombok

[Mike Power]

I would like to be able to maintain a high test code coverage in the
range of 95%. Obviously using lombok causes issues. This seems like it
would be a common problem, but searching the list did not pull up
anything interesting.

I did find:
http://stackoverflow.com/questions/10276666/lombok-annotations-vs-code-coverage-in-cobertura-or-similar-tool

Which at least helps cover the problem of identifying untested branches.

How have people solved code coverage with lombok? Solutions using
jacoco would be especially appreciated.

[Marvin Froeder]

I have being using lombok with JaCoCo and coverage works just fine.

Although it pin point all generated code to the annotation line, but
that ain't a problem for me, since I do consider generated code as 3rd
party =D

On Jul 17, 12:34 am, Mike Power <mpower.li...@dodtsair.com> wrote:
> I would like to be able to maintain a high test code coverage in the
> range of 95%.  Obviously using lombok causes issues.  This seems like it
> would be a common problem, but searching the list did not pull up
> anything interesting.
>

> I did find:http://stackoverflow.com/questions/10276666/lombok-annotations-vs-cod...

[Mike Power]

So do you ignore your low code coverage numbers?

[Marvin Froeder]

Well, my current coverage is always over 80% when combined UTs and ITs... 

On Sun, Jul 22, 2012 at 9:36 PM, Mike Power <mpower...@dodtsair.com> wrote:

So do you ignore your low code coverage numbers?

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/

To post to this group, send email to project-lombok@googlegroups.com
To unsubscribe from this group, send email to
project-lombok+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en

[Ricardo Cavalcanti]

Ressurecting the thread.

Currently, with cobertura one can ignore an annotated method with the ignoreMethodAnnotation parameter. Which could play well with the @java.annotation.Generated annotation added to all lombok generated methods if  @Generated didn't have SOURCE retention policy and code coverage tools didn't look at compiled code.

What about adding a custom lombok.config'ured annotation to all generated methods like COnstructors, Equals and hashcode, getters and setters so that this generated code could be excluded from coverage reports?

On Sunday, July 22, 2012 at 9:43:59 PM UTC-3, Marvin Froeder wrote:

Well, my current coverage is always over 80% when combined UTs and ITs... 

On Sun, Jul 22, 2012 at 9:36 PM, Mike Power <mpower...@dodtsair.com> wrote:

So do you ignore your low code coverage numbers?

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/

To post to this group, send email to project...@googlegroups.com

To unsubscribe from this group, send email to

project-lombo...@googlegroups.com

[Reinier Zwitserloot]

Sounds like a good idea, except for the notion that annotations can have parameters, and trying to parse these out of a config file is annoying.

Would it be okay if lombok adds this feature, _BUT_, you cannot specify any parameters for the annotation? You can say that you want all generated code to be annotated with @com.whateveryouwant.AnnotationNameHere, but that's where it ends – you can NOT say that you want all generated code to be annotated with @com.whateveryouwant.AnnotationNameHere(param1="foobar", param2=Whatever.class).

And, of course, you would configure this in the config system, not in your source files.

That wouldn't be too hard to add. Would that help?

Should lombok ship an annotation for this inside its own public packages? Something like lombok.Generated (and if we do, do we give it CLASS level retention or even runtime level)?

We could by default add this annotation to all the stuff we generate, but at that point we'd be adding 3 annotations to everything: SuppressWarnings, javax.annotation.Generated, and lombok.Generated. That's perhaps a bit much. Still, having it means you don't have to make one, you can tell lombok to add it everywhere, and then findbugs, or cobertura, or whatever other relevant tool to ignore it everywhere.

 --Reinier Zwitserloot

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel López]

If it had Runtime retention, would it mean we would need lombok at runtime now?

S!

D.

[Martin Grajcar]

On Sat, Jan 31, 2015 at 6:13 PM, Reinier Zwitserloot <rei...@zwitserloot.com> wrote:

We could by default add this annotation to all the stuff we generate, but at that point we'd be adding 3 annotations to everything: SuppressWarnings, javax.annotation.Generated, and lombok.Generated. That's perhaps a bit much.

Maybe there could a configuration switching it off in case somebody cares?

 

Still, having it means you don't have to make one, you can tell lombok to add it everywhere, and then findbugs, or cobertura, or whatever other relevant tool to ignore it everywhere.

Concerning issue 702, I'm not sure if it's  possible to configure Findbugs like this. This would be cleaner than configuring Lombok to add @SuppressFBWarnings, but OTOH I know how to configure Lombok, but have no idea how to do it for Findbugs using a Maven/Gradle/Whatever/Or/Something/Else and would prefer not to learn it for multiple tools.

On Sat, Jan 31, 2015 at 6:16 PM, Daniel López <d.lo...@gmail.com> wrote:

If it had Runtime retention, would it mean we would need lombok at runtime now?

 AFAIK no, see http://stackoverflow.com/q/3567413/581205.

[Michael Power]

When I had originally talked about this I wanted to integrate it with jacoco.  It might be useful to look at their feature request for an annotation implemented in their code.  They have a number of the same concerns

https://github.com/jacoco/jacoco/issues/14

Awhile ago we talked about some fancy string literal comment stuff to make it easier to copy and paste large bodies of text into java.  Jacoco had a similar idea of trying to use a comment for annotation.

Sent using CloudMagic

[Reinier Zwitserloot]

No, it just means that _if_ Lombok is on the classpath, you can figure out if a method was generated by it or not at runtime.

[Daniel López]

Cool. So, it means it would just have to be in the classpath when the tools analyse the binaries, else they won't see the annotation. It should not really be a be problem, just a configuration issue, but something to take into account as "silently ignoring if not present" might confuse users.

S!

D.

[Ricardo Cavalcanti]

On Saturday, January 31, 2015 at 2:13:32 PM UTC-3, Reinier Zwitserloot wrote:

Sounds like a good idea, except for the notion that annotations can have parameters, and trying to parse these out of a config file is annoying.

Would it be okay if lombok adds this feature, _BUT_, you cannot specify any parameters for the annotation? You can say that you want all generated code to be annotated with @com.whateveryouwant.AnnotationNameHere, but that's where it ends – you can NOT say that you want all generated code to be annotated with @com.whateveryouwant.AnnotationNameHere(param1="foobar", param2=Whatever.class).

And, of course, you would configure this in the config system, not in your source files.

That wouldn't be too hard to add. Would that help?

As far as Cobertura is concernes, you just need the annotation as a marker, no params are needed. It could be either a custom configuration, or a specific lombok.Generated, as long as it has at least Class retention. A custom one seems more plausible for that case when one wouldnt want lombok in the  runtime classpath

  

Should lombok ship an annotation for this inside its own public packages? Something like lombok.Generated (and if we do, do we give it CLASS level retention or even runtime level)?

We could by default add this annotation to all the stuff we generate, but at that point we'd be adding 3 annotations to everything: SuppressWarnings, javax.annotation.Generated, and lombok.Generated. That's perhaps a bit much. Still, having it means you don't have to make one, you can tell lombok to add it everywhere, and then findbugs, or cobertura, or whatever other relevant tool to ignore it everywhere.

Don't thing it would be too much, since both  javax.annotation.Generated and SuppressWarnigns are dropped after compilation.