This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Wrong coverage metrics for FastAPI project #3557
Comments
Maybe related to nedbat/coveragepy#1082 ? |
@Kludex Yes, looks like it. It was exactly my case: I have a FastAPI together with SQLAlchemy async calls. After reading the thread and other related threads carefully I noticed that coverage report in my project stopped after async calls to SQLAlchemy engine. As I understood the reason for it is that FastAPI uses threads, and SQLAlchemy uses greenlet to provide async behavior and coverage has problems tracking both in the same project. I tried to play around with the coveragerc settings and came out using "concurrency=greenlet" config. So far, the report looks much better and shows hits on the code lines after SQLAlchemy async calls. I will check it further on. Thank you for the link. I would definitely not have dug it out by myself! |
I'm also testing against a FastAPI project with a mix of async routes, async SQLAlchemy and synchronous FastAPI dependencies. Instructing coverage to use Adding a voodoo |
A fix for this has been merged to the coverage repository. Once the new coverage version is out you will be able to specify multiple |
2effdb0 tiangolo/fastapi#3557 nedbat/coveragepy#1082 https://coverage.readthedocs.io/en/6.2/config.html pyproject.toml had an unnecessary `--concurrency=multiprocessing` config setting, which had been added in 2effdb0 to avoid "very wrong results," as worded in the coverage.py docs. Tests do use the multiprocessing package, but don't actually start multiple processes, so the setting is not needed. After updating to coverage.py 6.2, reports incorrectly showed FastAPI and Starlette TestClient route code as uncovered, when it actually was. Removing the concurrency setting from pyproject.toml resolves the issue.
After reading the above and making sure I had a recent version of coverage ( [coverage:run]
concurrency =
greenlet
thread |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Hi everyone. I am having an issue with pytest coverage report for my FastAPI project.
Part of the code, which is definitely executed is not market as covered. Namely return statements from routes.
Did anybody here have this issue? I have seen only one mention of it in stackoverflow, but not resolved.
Thank you
The text was updated successfully, but these errors were encountered: