Report covered 'no-cover' lines

[nedbat]

Originally reported by Anonymous

---

It is often the case that a feature will be added in one commit, but there isn't any client code that calls a particular method yet. As such, the method is marked

pragma: no cover

coverage passes and everyone continues along their merry way.

Later, when client code is added that exercises that code path, it would be nice if coverage.py could complain saying something like
"WARNING: Block marked 'no cover' actually covered. You may want to remove the pragma."
That way, we could continually make sure that the minimum amount of code is under 'no cover' pragmas.

---

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/251

[nedbat]

Hmm, I'm not sure I approve of pragma'ing away code that you intend to cover eventually, but it's an interesting idea to alert the user to unneeded pragmas.

[nedbat]

Original comment by John Vandenberg (Bitbucket: jayvdb, GitHub: jayvdb)

---

In my experience, #pragma: no cover is most often used for OS specific paths.
These proposed alerts would be a good way to advertise that platform specific code can be properly required when the tests are being run on the respective hosts using env vars https://bitbucket.org/ned/coveragepy/issues/563

The only complexity is whether this alert is only added for the default #pragma: no cover, in which case you would want to add another default which doesnt trigger the alert, and/or a way to turn off the warning (but imo the ecosystem is improved if the warnings cant be easily disabled, as it is important that coders limit when the block isnt covered to specific conditions).

[nedbat]

Original comment by Andrei Fokau (Bitbucket: andreif, GitHub: andreif)

---

Wonderful idea, all exclude_lines number should be reported.
Maybe even omitted *.py files as well.

[nedbat]

Issue #619 was marked as a duplicate of this issue.

[nedbat]

Original comment by Toshio Kuratomi (Bitbucket: toshio, GitHub: toshio)

---

Looking at the code handling exclusions, it appears that exclusions are recorded and tracked all the way up to Coverage.Analysis but the excluded lines are being removed from executed statements at a much lower level, when we parse the python file. To implement this, I think we need to keep excluded lines in the executed statements until much later. I think Analysis makes sense for that as it is where other statistics get combined and calculated before the Reporter phase.

[nedbat]

Original comment by Toshio Kuratomi (Bitbucket: toshio, GitHub: toshio)

---

(Just FYI: I am using exclude_lines similar to jayvdb, I want to exclude lines that can only run on Python2 or only run on Python3 when the Python interpreter running them is the opposite version. These lines are essentially dead code on that version of Python. I want coverage to warn me if that code is being executed on that Python version as it means either my code is wrong or my marking of it as dead code on python2/3 is wrong.)

[adrien-berchet]

Did anything move forward on this topic? I would really like this feature for the exact same reason as the one originally reported here.

[nedbat]

Sorry, nothing new has happened.

[adrien-berchet]

Hi @nedbat
No problem, thanks for the answer, it was just to be sure I did not miss something.
I am quite surprise that this feature is not much requested while it seems very important to me :)

[nedbat]

Thinking about this more, there's a subtlety here. Let's say I have some code that is only for Windows and I only run my tests on Linux. I might put this in my configuration file:

[report]
exclude_lines =
    if WINDOWS:

This has the advantage that the entire clause beneath the if is excluded:

    blah_bla()                      # line 1

    if WINDOWS:                     # line 3
        windows_thing()             # line 4
        another_windows_thing()     # line 5

    more_blah()                     # line 7

Here, lines 3,4,5 will be excluded. But line 3 is executed, when the test for WINDOWS happens, and is false.

Simply reporting on the excluded lines that were executed would report line 3, which is not interesting.

Do other people use exclude_lines like this? Ideally, this should report that no excluded lines were executed.