Uncovered files from dirs without __init__.py are not reported

[pytest-dev]

Uncovered files from dirs without __init__.py are not reported

[remort]

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]

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

[blueyed]

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?!)

[junaruga]

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.

[sylvain-ri]

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

[ionelmc]

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]

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

[ionelmc]

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]

👍 same here

[ionelmc]

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

[codingjoe]

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]

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

[codingjoe]

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

[ionelmc]

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

[blueyed]

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?!

[ionelmc]

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