Skip to content
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

Uncovered files from dirs without __init__.py are not reported #88

Closed
blueyed opened this issue Sep 11, 2015 · 16 comments
Closed

Uncovered files from dirs without __init__.py are not reported #88

blueyed opened this issue Sep 11, 2015 · 16 comments
Labels

Comments

@blueyed
Copy link
Contributor

blueyed commented Sep 11, 2015

It seems like files that are not imported/used are not reported as having 0% coverage.

It would be useful if all the files of the project would be in the coverage report - having a percentage of 0% in case they were not imported/used.

I could imagine that pytest-cov would have to hook into py.test's collection process for this, and then somehow make coverage aware of them - even if they are not imported during tests?!

@ionelmc
Copy link
Member

ionelmc commented Sep 11, 2015

This feature is built into coverage, but with a caveat: you have to use paths for the source.

Eg: if you use py.test --cov=somepath then you'll get all files in somepath in the report.

@blueyed
Copy link
Contributor Author

blueyed commented Sep 11, 2015

And that's not covered by [paths] source = X and/or [run] source = X?

@ionelmc
Copy link
Member

ionelmc commented Sep 11, 2015

Not really sure, but it sounds like it's not something pytest-cov specific. What behavior do you get if you use plain coverage (eg: coverage run -mpytest tests)?

If you put an example somewhere I'll take a look.

@codingjoe
Copy link

👍 same here

@ionelmc
Copy link
Member

ionelmc commented Sep 22, 2015

@codingjoe are you having the same issue or you're waiting too on some example that reproduces the issue? 😁

@codingjoe
Copy link

Never mind problem gone. I had the same problem too, but only once. Now it's gone, very curious. Made my coverage skyrocket. Now it's back to "normal".

@ionelmc
Copy link
Member

ionelmc commented Sep 22, 2015

@blueyed Can you create some minimal project that reproduce the issue? Or at least point to the project that has this problem ...

@codingjoe
Copy link

I can't even recreate the issue myself. So no, sorry.

@blueyed
Copy link
Contributor Author

blueyed commented Sep 23, 2015

This happens because of a missing __init__.py file.

coveragepy skips it then (https://github.com/nedbat/coveragepy/blob/e7c532c2dbcef6281df5a7a0db53eca4083a026a/coverage/files.py#L342-L346).

This gets used in Coverage.get_data (https://github.com/nedbat/coveragepy/blob/e7c532c2dbcef6281df5a7a0db53eca4083a026a/coverage/control.py#L823-L831).

I think that also "non-importable" files should be included - but that is an issue to raise for coveragepy then probably?!

In my case the __init__.py file was missing in project/app/management/__init__.py, but that is no problem for Django itself - the commands can be used.
(Maybe that's because project/app/management/commands/__init__.py exists?!)

@blueyed blueyed changed the title Include all files in the report Dirs without __init__.py are skipped Sep 23, 2015
@blueyed blueyed changed the title Dirs without __init__.py are skipped Uncovered files from dirs without __init__.py are not reported Sep 23, 2015
@ionelmc
Copy link
Member

ionelmc commented Feb 14, 2016

Do we have a bug report for this in https://bitbucket.org/ned/coveragepy?

@blueyed
Copy link
Contributor Author

blueyed commented Feb 14, 2016

I could not find one, and given the comment in https://github.com/nedbat/coveragepy/blob/d5a89ab843542f88544a0f55900093329ef6b85c/coverage/files.py#L331-L346 it might even be not possible?!

@junaruga
Copy link

Though I am not sure my case is same case with this report.
I was succeeded to report files in directory without __init__.py in my case.

$ cat .coveragerc 
# https://coverage.readthedocs.io/en/latest/config.html
[run]
include =
    rpm_py_installer/*
    install.py
    setup.py
$ pytest --cov-config .coveragerc --cov . tests
...
Name                           Stmts   Miss  Cover
--------------------------------------------------
install.py                       325     27    92% <=== This file is not in __init__.py's directory, and reported here.
rpm_py_installer/__init__.py       0      0   100%
rpm_py_installer/version.py        1      0   100%
setup.py                          35     35     0%
--------------------------------------------------
TOTAL                            361     62    83%

See rpm-py-installer/rpm-py-installer#59 for detail.

@ionelmc
Copy link
Member

ionelmc commented Oct 28, 2017

Closing this in favour of #176. Add your thoughts there if you want your usecase documented.

@ionelmc ionelmc closed this as completed Oct 28, 2017
@remort
Copy link

remort commented Jul 31, 2020

Problem with modules placed in dirs without init files is still exists, while
#176 is closed.

The bug is still exists. In python 3 modules (.py files) doesn't need init files be placed nearby to be able code from these files to be imported. I don't use init files and always import code directly from .py files. The whole lotta applications written without init files and pytest do not cover such dirs (if code from files is not imported or tested somehow in tests runned by pytest).

@sylvain-ri
Copy link

The current solution is to use include_namespace_packages = True
https://coverage.readthedocs.io/en/7.0.0/config.html#report-include-namespace-packages

@sylvain-ri
Copy link

For people also ending here, there is the solution:
add a config file for your pytest-cov command pytest --cov=<folder> --cov-config=.coverage_rc

Content of .coverage_rc

[report]
include_namespace_packages = true

# might also be convenient to add one of these:
omit = **/__init__.py
skip_empty = true

Adapt the heading to [tool.coverage.report] if within a pyproject.toml file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants