sbt-coverage icon indicating copy to clipboard operation
sbt-coverage copied to clipboard

Code coverage reports fail to address scala specific features

Open sroebuck opened this issue 14 years ago • 4 comments

It has been noted that the code coverage reports do not seem to account for Scala specific features like case classes. The common reported issue is that the reports show red bars (low coverage) for such code when the code appears to be well covered.

This issue raises more questions as to how the coverage should be worked out:

  1. Do we count additional code produced for case classes as part of the declaration line of the class or somehow represent these bits of code elsewhere? The former makes a lot of sense but fails to depict which bits of the auto generated case class code are accessed and how much.
  2. Do we consider a failure to cover the auto generate code as low coverage or do we consider the autogenerated code to be automatically correct and therefore authomatically covered?

I'd really welcome comments on this issue.

sroebuck avatar Feb 03 '11 00:02 sroebuck

Not 100% sure what you are asking, but let's take an example: case class Person(firstName: String, lastName: String) => That should not produce red bars / low coverage

hseeberger avatar Feb 03 '11 00:02 hseeberger

Do you agree that: case class Person(firstName: String, lastName: String) should have red bars if it is not used at all by your test code? If it is a code coverage tool in the literal sense then that is what you would expect.

If you do agree on the above, then what about code that uses the companion object constructor but not the auto generated toString method?

If someone wants to use code coverage as a way of ensuring a good set of tests are in place then case class boilerplate shouldn't generate red bars, but if it is being used to genuinely identify what code is exercised by the tests and how frequently calls are made (perhaps to assist in optimising the code) then it may be valuable to know that the code is repeatedly calling the toString method or the equality function or whatever.

Does that help to explain the question better?

sroebuck avatar Feb 03 '11 07:02 sroebuck

Thanks for the clarifications!

I am talking about test coverage, not code coverage, i.e. I am interested in knowing, whether all relevant code is tested. I don't consider compiler generated code as relevant in this sense.

hseeberger avatar Feb 03 '11 09:02 hseeberger

I agree with hseeberger for what is what.

ijuma avatar Feb 15 '11 11:02 ijuma