groovy

Better Cobertura Support

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.5.7, 1.6-beta-2
  • Fix Version/s: 1.6-rc-1, 1.5.8, 1.7-beta-1
  • Component/s: bytecode
  • Labels:
    None
  • Number of attachments :
    1

Description

I am one of the Cobertura developers. A guy named Dustin Barnes recently asked a question on the Grails mailing list concerning some weird behavior he was seeing while using the grails/cobertura plugin.

The Eclipse project that I used to investigate is attached.

I would like to verify the behavior I am seeing and see if something can be done to improve the coverage reports.

First issue: Source line numbers for Groovy class constructors (not closure constructors) do not seem to be included in the bytecode. Therefore, the constructors are ignored in the reports. This is a good thing if no constructors are in the source, but not if there are constructors in the source.

Second issue: when a closure is defined the line number information is put in the constructor of the closure. If you do nothing other than construct the owner, it appears all the closures' constructors are executed. In my Eclipse project, I created a MyGoodController class with two empty closures defined. If I write a test that does nothing other than new MyGoodController(), I see a report that shows two green lines at the two closure definitions. This is misleading because the closures were not called.

Next issue: Dustin figured out that there is a big difference in reports depending on whether or not constructors are defined in a class. Let me explain in detail. In my project, I defined a class called MydomainController. In addition to the exact two closures defined in MyGoodController, I defined two constructors. If you have one constructor, everything looks OK except that the constructor is ignored in the report because of missing line numbers (issue #1 above). However, if two constructors are defined, one closure has a green line, and one has a red line. The point is that it looks different from the MyGoodController report when the test is essentially the same - the script class is constructed and no closures are called.

Looking at the bytecode, I'm seeing the following:

MydomainController.class:
_closure1 constructor shown as line 10
_closure2 constructor shown as line 12
_closure3 constructor shown as line 10
_closure4 constructor shown as line 12

So, I'm assuming 2 closures are created for each constructor. According to the report, _closure2 and/or _closure4 were constructed, but _closure1 and _closure3 were not. Is this possible?

John

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
blackdrag blackdrag added a comment -

Trunk contains now a fix for issue 1.

Show
blackdrag blackdrag added a comment - Trunk contains now a fix for issue 1.
Hide
Permalink
blackdrag blackdrag added a comment -

a fix for issue 2 is now in trunk. the closure constructor will now no longer have a line number, with the effect, that the report does not green the closures automatically. .. unless they are really called of course

Show
blackdrag blackdrag added a comment - a fix for issue 2 is now in trunk. the closure constructor will now no longer have a line number, with the effect, that the report does not green the closures automatically. .. unless they are really called of course
Hide
Permalink
blackdrag blackdrag added a comment -

the third issue is not so easy to fix, because in a class

class X {
  X(){}
  X(o){}
  def p = {}
}

Groovy generates actually something like:

class X {
  X(){
   p={}
  }
  X(o){
   p={}
  }
  def p 
}

meaning, that the one closure did become two all of a sudden. Groovy would have to reuse the class it generated for one of these constructors.

Show
blackdrag blackdrag added a comment - the third issue is not so easy to fix, because in a class class X { X(){} X(o){} def p = {} } Groovy generates actually something like: class X { X(){ p={} } X(o){ p={} } def p } meaning, that the one closure did become two all of a sudden. Groovy would have to reuse the class it generated for one of these constructors.
Hide
Permalink
blackdrag blackdrag added a comment -

this should be fixed now

Show
blackdrag blackdrag added a comment - this should be fixed now

People

  • Assignee:
    blackdrag blackdrag
    Reporter:
    John Lewis
Vote (27)
Watch (15)

Dates

  • Created:
    Updated:
    Resolved: