coverage reports 0% of coverage for covered files #1034
Comments
|
Try using |
|
Thx for the tip Ned. When i run the command the paths seem correct. |
|
It looks like it's difficult to use the debugger in combination with coverage.py however i found that with the exact same code i don't have the same result if i run a specific test file or a test folder When running one file with I get the expected result However when i run it on the folder The result is different: I'll try to add some logs |
|
Ok I found the origin of the issue. In another file test in the same folder i left an |
|
I'm not sure what the warning would be for. Coverage uses the same interpreter hooks that debuggers do. There might already be a warning. If you run pytest with the -s flag (to allow all output), do you see a waning about "Trace function changed"? |
|
i tried to run it with -s option but i don't see any log or warning. |
|
I have probably the same issue (on Linux, CentOS 8.2), therefore I will add my observations here (I've tested with python 3.7.9, coverage 5.5): I want to make a coverage run in a folder structure like this with the command: The report gives me correct values for dir1, which is a python package defined in the setup.py on the first level. For the files in dir2, where the setup.py is on the same level as the *.py files, I get always 0 line coverage. On Windows (with coverage 5.4), this works as expected, with non-zero line coverage of dir2/*.py files. |
|
similarly using a tox environment I experience this issue. Packages in setup.py are appropriate assigned as However, when I organized the files like this: Maintaining that |
|
Can you give me a reproducible scenario? |
|
@nedbat https://github.com/hdost/pycoverage-failing I've put a minimal example where I could there's a main and a "working-example" branch |
|
I have the same issue, with my configuration: Python 3.7 I see that code was called, but coverage reports 0% for all file. |
|
@vyosypenko as always, it's really helpful if you can give me a reproducible scenario. |
|
@hdost Thanks for your reproduction, and sorry it's taken me so long to get to it. To debug these cases, it's useful to add If you search for primary.py in that output, you see this: The code is installed in site-packages, and running from there. Your --source option is specifying a different directory than that, so no data is collected. If you add this option to tox, it will run your code from your working tree instead of installing it, which will fix the problem: If you don't want to use usedevelop, then remove the Then the result is: |
|
@nedbat, .coveragerc file: [run] [report] omit = exclude_lines = all python code is located in the source folder: source env/bin/activate python -m pytest --cov="$(pwd)" internal_tests/testlist.py --disable-warnings the file with 0% coverage: Copyright Information""" |
|
@nedbat, |
|
Was hunting down this 0% coverage issue on my side, ended up being something stupid, thought I'd share! I installed my local package with |
I had the same issue and spent half a day debugging this. So my project's folder structure looks like this: project-name/ And the problem was I was first running |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Test coverage for my project returns a lot of file with 0% of coverage even if i have unit test for them.
Even the code in global scope is marked uncovered
while this module is correctly imported
To Reproduce
How can we reproduce the problem? Please be specific. Don't just link to a failing CI job. Answer the questions below:
Python 3.6.9
coverage debug sysis helpful.pip freezeis helpful.It's a private GithubEnterprise repository where i have a flask application that loads some data from a postgres application.
Note that i run those tests in docker but i use the same config for another project that runs fine so i suspect something specific in my project.
Expected behavior
I expect to have 100% code coverage on my files instead of 0%
The text was updated successfully, but these errors were encountered: