Code Coverage Tools for Scala

Question

What are the available code coverage tools for Scala?

I have Scala spec tests and a Hudson continuous integration set-up. Is there something I can hook-in to this setup to measure and track code coverage?

it is stunning to me that this was closed as not constructive. heck, 33 people upvoted it. 6 people answered it with a combined 43 upvotes. but somehow it's not constructive for the community? 'cmon, y'all. with utmost respect and love I'd suggest learning a bit about pedagogy as well as changing "the rules" of "our Q&A format". — ari gold, Sep 21 '15 at 19:49
Agreed. If you don't like this being closed, vote to re-open. — Ira Baxter, Oct 08 '15 at 07:10
3000 reputation threshold seems arbitrary and doesn't make sense across the board. In certain esoteric areas, the participants may not have or generate sufficient reputation. I bet if the same question came up in Python, a good number of participating voters would have sufficient reputation to have this reopened. — Benny, Jul 30 '20 at 23:52

score 18 · Answer 1 · answered Oct 11 '10 at 10:19

18

SCCT is a compiler plugin which instruments the classes to gather coverage data:

http://mtkopone.github.com/scct/

answered Oct 11 '10 at 10:19

Joni

2,779
23
17

afaik there is no way to hook SCCT into Hudson? – Paul McKenzie Aug 23 '12 at 15:03
3

SCCT is now scoverage. – mmlac Aug 07 '15 at 20:10

score 9 · Answer 2 · edited Dec 27 '11 at 18:23

9

Undercover is little better.

edited Dec 27 '11 at 18:23

answered Aug 07 '09 at 10:29

user152392

91
1
1

8

A little bit better than what? – KajMagnus Aug 10 '13 at 04:06

score 9 · Answer 3 · answered Jun 05 '09 at 07:01

9

I use Cobertura. However, any Java coverage tool should work just fine. The only catch is that you will end up with a large number of auto-generated classes in your coverage list. This is because while Scala compiles down into very natural JVM bytecode, it is forced to produce an unnaturally large number of classes to accommodate common functional features like lazy evaluation.

answered Jun 05 '09 at 07:01

Daniel Spiewak

54,515
14
108
120

This is the classic problem of instrumenting something other than the source code: you noise up the answer. See discussion of related troubles when instrumenting class files rather than source files at this SO answer: http://stackoverflow.com/a/15260092/120163 – Ira Baxter Jan 26 '15 at 18:58

score 8 · Answer 4 · answered Mar 02 '11 at 23:00

One problem with non-mainstream languages (such as Scala) is that tools are hard to find, because they are hard to build.

This technical paper Branch Coverage for Arbitrary Languages Made Easy (I'm the author) describes how to build test coverage tools for langauges in systematic way to help get around this problem, using a generic tool-building infrastructure.

We've implemented test coverage tools for Java, C#, COBOL, C, C++, PL/SQL, ... this way, including instrumenters, data collection and test coverage display and reporting. It would be straightforward to implement Scala like this.

The solutions posed by other answers produces confusing information from the implementation of Scala ("auto genreated classes"). What developers want to see is coverage data in terms of their code. The approach we use instruments the source code, so the results are stated entirely and only in terms of the source code; even the test coverage viewer shows the source code covered with coverage information.

score 4 · Answer 5 · edited Dec 12 '11 at 09:22

I use jacoco. It does not require compile- or runtime- dependencies, instruments classes on the fly w/o special instrumentation phase.

Also it integrated with Sonar and published on Maven Central.

Here is example: https://github.com/Godin/sonar-experiments/tree/master/jacoco-examples/scala-example

I would like to add better reporting: more detailed branch coverage makrup, excluding of generated classes/methods, and to be handy like ScalaDoc (see SCCT reports for example)

score 3 · Answer 6 · answered Mar 11 '13 at 13:47

I've put together a SBT plugin called xsbt-coveralls-plugin that uses scct under the hood, but publishes the results to http://coveralls.io.

Disclaimer: I've only just built this plugin yesterday (10th March 2013) so don't expect it to be perfect yet, but do send bugs and feature requests to the github page

Still, it's good if you want to code coverage reports to be publicly visible. Check out an example of the results here

Code Coverage Tools for Scala

6 Answers6

Linked