From issue #8
The covtracer output here is pretty generic. We can do some filtering if we want to present other information. By default, NAs are included for documented objects that are untested. As well, there may be situations where the test_name is unknown, but there is still testing code that prompts package execution (often this is test setup code, outside of any test_that() call).
In the covtracer README, I include these columns just to illustrate the missingness of code coverage. In a report, I would choose other, more meaningful columns - I would drop test_name and count, and instead filter out unexported documentation (filter(is_exported = TRUE)) to only show untested, exported functions as those are a better indicator of the user contract of a package. Just for the sake of clarity, it might be nice to have a clean "No untested behavior" if the resulting table has no records instead of just showing an empty table.
Originally posted by @dgkf-roche in #8 (comment)
From issue #8
The
covtraceroutput here is pretty generic. We can do some filtering if we want to present other information. By default,NAs are included for documented objects that are untested. As well, there may be situations where thetest_nameis unknown, but there is still testing code that prompts package execution (often this is test setup code, outside of anytest_that()call).In the
covtracerREADME, I include these columns just to illustrate the missingness of code coverage. In a report, I would choose other, more meaningful columns - I would droptest_nameandcount, and instead filter out unexported documentation (filter(is_exported = TRUE)) to only show untested, exported functions as those are a better indicator of the user contract of a package. Just for the sake of clarity, it might be nice to have a clean "No untested behavior" if the resulting table has no records instead of just showing an empty table.Originally posted by @dgkf-roche in #8 (comment)