covr icon indicating copy to clipboard operation
covr copied to clipboard

Reporting functions with no coverage

Open fangly opened this issue 8 years ago • 5 comments

Hi,

covr looks great and I am trying to integrate it (version 2.2.2) in my workflow. Specifically, I am interested in detecting functions that have no coverage at all.

Using zero_coverage(), one can tally_coverage() by line or expression. But is it at all possible to tally by function? Did I miss something obvious? print.coverage() has an option to group by function and it seems like something similar would be great for zero_coverage().

Cheers,

Florent

fangly avatar Jan 16 '17 17:01 fangly

You did not miss anything, this is an area that really needs some refactoring in covr. The print method does both printing and grouping and the grouping should really be done by another function.

jimhester avatar Jan 16 '17 18:01 jimhester

This is a similar issue to https://github.com/jimhester/covr/issues/241

jimhester avatar Jan 16 '17 18:01 jimhester

@jimhester, I think that what I'm about to describe is related to this issue, but if you feel it is better as a separate issue, please let me know.

In eddelbuettel/digest#130, I suggested using a simple function assignment to cover generic S3 methods. The reasonable response was that they want to ensure coverage is maintained for all classes. I wonder if it is possible as part of checking the package to get a list of all functions in the package and somehow ensure that each of the functions is called? (I believe that this is an identical ask to the above.)

I do see a complexity since covr is based on coverage of lines a valid assignment of functions could look like the following with everything on one line.

sha1.call <- sha1.character <- sha1.factor <- sha1.integer <- sha1.logical <- sha1.raw <- sha1_attr_digest

And, I would consider it a perfectly valid requirement that to have coverage confirmed, it would have to look like the following instead:

sha1.call <-
 sha1.character <-
 sha1.factor <-
 sha1.integer <-
 sha1.logical <-
 sha1.raw <-
 sha1_attr_digest

(Ideally with a warning for the former case that line-based coverage may not work.)

While I don't know practically anything about the internals of covr, perhaps the test for line coverage could be:

  1. If there is a single assignment on the line to function() and it is called at least once, it is covered.
  2. If there is a single assignment on the line to something that is eventually a function (like the second case above), and it is called at least once, it is covered.
  3. If there are multiple assignments on the line to something that is eventually a function (like the first case above), all of the functions must be called at least once for the line to be covered.
    1. Or, simpler could be if there are multiple assignments on the line to something that is eventually a function (like the first case above), it is never considered covered, and there is a warning to the user that only single assignments per line are allowed. (Likely simpler, but I understand that would also likely generate more queries about why the line is not covered.)

billdenney avatar Nov 06 '19 14:11 billdenney

top level assignments are run when the package is built, e.g. during install time. covr measures what code is run during tests, this is not going to change.

jimhester avatar Nov 06 '19 17:11 jimhester

Thanks for the quick answer, and that makes sense to me now.

billdenney avatar Nov 06 '19 22:11 billdenney