Skip to content

Coverage gets confused when encoding comment is in the wrong place #443

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nedbat opened this issue Nov 9, 2015 · 2 comments
Closed

Coverage gets confused when encoding comment is in the wrong place #443

nedbat opened this issue Nov 9, 2015 · 2 comments
Labels
bug Something isn't working

Comments

@nedbat
Copy link
Owner

nedbat commented Nov 9, 2015

Originally reported by David MacIver (Bitbucket: david_maciver_, GitHub: Unknown)


It seems that code which incorrectly has things before the encoding comment confuses coverage.

Reproduction:

conventions.py:

from __future__ import division, print_function, absolute_import


# coding=utf-8

class UniqueIdentifier(object):

    def __init__(self):
        pass


not_set = UniqueIdentifier()

test_conventions.py:

import conventions

Then running the following:

python -m coverage run test_conventions.py && coverage report --show-missing

Causes coverage to report that the file conventions.py has not got 100% coverage (it does), but also gives nonsensical line numbers:

Name                  Stmts   Miss  Cover   Missing
---------------------------------------------------
conventions.py            5      3    40%   4, 7-10
test_conventions.py       1      0   100%   
---------------------------------------------------
TOTAL                     6      3    50%   

Line 4 is the encoding comment, and lines 7-10 correspond to the class body.

I have tested this on Python 3.4.3 running coverage 4.0.2. I noticed this when my CI started breaking (I erroneously had some code like this due to a confused formatter) on a coverage upgrade, so I think it's probably introduced in a recent version.


@nedbat
Copy link
Owner Author

nedbat commented Nov 10, 2015

It's definitely reproducible, and it definitely appeared in 4.0.2. Thanks for the edge cases!

@nedbat
Copy link
Owner Author

nedbat commented Nov 14, 2015

Fixed in a51232f360ef (bb), aiming for 4.0.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant