You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We use pragma: no cover to mark sections of code that are impractically difficult to test. This way, we can use "100% coverage" to mean "we have made a conscious decision to not test some code" or "there is nothing untested by accident".
That said, all that deliberately, consciously untested code is still a risk. It would be nice to know how much of a risk we're carrying by having some way to identify excluded code.
Describe the solution you'd like
The coverage report should also include the number of lines excluded.
Describe alternatives you've considered
Grepping for no cover gets us a part of the way, and is a reasonable way of auditing. It's hard to guess how much damage any individual no cover might cause.
Additional context #251 is very similar, but is about reporting on excluded lines that ended up being covered.
The text was updated successfully, but these errors were encountered:
This is an interesting idea. I guess you are talking about the text report (coverage report)? We could add a column to count the excluded lines. Have you looked at the HTML report? It already has a column for Excluded, and the individual file pages can show the excluded lines (highlighted in gray).
Thanks! Yes, I am talking about the text report. I think what I'd really like is both a column as you describe and a --show-excluded option that shows line numbers of statements in each module that were excluded.
I didn't know that about the HTML report—that's neat! I don't look at it very much since our build automation runs the text report. I'll definitely use it next time I'm on a coverage-improving rampage.
Is your feature request related to a problem? Please describe.
We use
pragma: no cover
to mark sections of code that are impractically difficult to test. This way, we can use "100% coverage" to mean "we have made a conscious decision to not test some code" or "there is nothing untested by accident".That said, all that deliberately, consciously untested code is still a risk. It would be nice to know how much of a risk we're carrying by having some way to identify excluded code.
Describe the solution you'd like
The coverage report should also include the number of lines excluded.
Describe alternatives you've considered
Grepping for
no cover
gets us a part of the way, and is a reasonable way of auditing. It's hard to guess how much damage any individualno cover
might cause.Additional context
#251 is very similar, but is about reporting on excluded lines that ended up being covered.
The text was updated successfully, but these errors were encountered: