jacoco for scala - inaccurate results?

248 views
Skip to first unread message

Damian H

unread,
Nov 20, 2012, 2:30:40 AM11/20/12
to scala...@googlegroups.com
Does anyone have any experience using the Jacoco code coverage tool for Scala? It seems to be reporting inaccurate results.

For example, when I test App.main on the code below, it's showing a yellow diamond and yellow line on line 10, meaning partial branch and partial line coverage respectively. It looks like that line is fully covered to me.

Am I missing something? Anybody any ideas on how to fix this?

Thanks

Damian.


  1. object
    App {

  2.  
  3.   def main(args : Array[String]) {
  4.     val myList = List(1,2,3)
  5.     println("Length of " + myList + " is: " + listLength(myList))
  6.   }
  7.  
  8.   def listLength[A](list: List[A]) : Int = {
  9.     list match {
  10.       case Nil => 0
  11.       case head :: tail => 1 + listLength(tail)
  12.     }
  13.   }
  14. }

Damian H

unread,
Nov 20, 2012, 4:38:37 AM11/20/12
to scala...@googlegroups.com
Just realised that the line numbers changed. The line in question is:

'    list match {'

Daniel Sobral

unread,
Nov 20, 2012, 6:05:03 AM11/20/12
to Damian H, scala-user
I use SCCT, which has been pretty consistent to me. The things it marks as not covered by tests are:

1. Abstract methods;
2. Final vals without types on objects (these are compiled as constants, but the getters are preserved).

These are annoying, but predictable enough as not to cause problem.
--
Daniel C. Sobral

I travel to the future all the time.

Damian H

unread,
Nov 20, 2012, 6:48:41 AM11/20/12
to scala...@googlegroups.com, Damian H
good to know Daniel, thanks.

Damian H

unread,
Nov 21, 2012, 9:56:47 AM11/21/12
to scala...@googlegroups.com, Damian H
I had this email from Paul Phillips on this topic:

>> For example, when I test App.main on the code below, it's showing a yellow diamond and yellow line on line 10, meaning partial branch and
partial line coverage respectively. It looks like that line is fully covered to me.


"That line, from the perspective of bytecode analysis, is something along the lines of

   if (list == null) throw new MatchError else ...

And the null branch is never taken. I imagine it will stop complaining if the match were written

  case head :: tail => ...

  case _ => 0

because it would no longer have to perform the null check."

Are general Java code coverage tools are doomed to produce too much noise / require too many work-arounds to be useful for Scala?

Scct doesn't suffer from this problem, but it would be useful to use Jacoco for the extra coverage metrics. 


Reply all
Reply to author
Forward
0 new messages