Repository navigation
Design proposal for test coverage #22827
Description
With the creation of the coverage API in vscode core, it is now possible to enable coverage for the python extension specifically. Below is the proposed design for how test coverage will work and includes some outstanding questions. Comments welcome as we are still in the design stage.
UX
Users can configure their coverage arguments in a similar way to how all run/debug/discovery args for testing. With the redesign of how testing arguments work with the extension of custom arguments this will be the entry point for coverage arguments. There is a new TestRunProfile kind of type coverage which will allow users to configure coverage specific configs that we will use to run coverage.
Secondly the entrypoint to run will be the buttons and other surfaces implemented in core and the default coverage config will be used unless a different one selected.
Implementation:
To implement coverage, the coverage.py library will be used. Our proposal is to not ship coverage.py and instead take the same approach as with pytest where the user must install coverage.py in their environment to use. This means that to utalize, a user will need to 1- install coverage.py, 2- create a coverage config, 3- select to run coverage.
Engineering design:
User coverage args will be sent to the python subproccess in the same means as any test args
if coverage.py is installed, and the coverage args are provided, then coverage will be calculated as described below
using the coverage.py API the python subprocess would then build a coverage payload
the payload design would include:
This would mean that coverage would support line based coverage (statement is the finite unit for coverage by vscode but python's smallest unit is line)
Due to the fact that branch coverage only lists the covered branch, and not the branches missing coverage, branch coverage will not be included at this time. If total branches can be calculated this can be reconsidered as an additional coverage stat provided.
The coverage payload will be read by the extension and displayed to the users
Other Design Concept:
The following idea was also considered: instead of using payloads for communication instead the team considered using the coverage file, like .coverage converted to XML and then read by the extension to parse the coverage and display. The pro of this would be the increase in separation between coverage and the base testing implementation that might make it easier to break out the coverage work into its own extension in the future. The con to the idea is that it will require the testing subprocess to send via information over a socket/pipe and a file thus duplicating the means of communication. It would also mean that the extension would do the heavy lifting in regards to taking the XML coverage data and converting it into the correct information design instead of doing this work on the python side. This fact would be contrary to our goal of increasing our percentage of python in the extension. ultimately we are leaning towards the first design outlined but are still open to discussion.
Given the proposal the following questions still exist:
- What happens if a person has coverage.py installed, has a config of type coverage but does not include any argument to enable coverage in this config? It is required to put "" if you want to use coverage (to turn it on) but this could be confusing for users since they selected a coverage run so they might expect it to work without the adding arguments step. One option here is to just check that all coverage runs have the right args to run coverage before spinning up the subprocess.
Activity
amankhandelia commentedon Apr 25, 2024
Do we have a timeline for implementation of the same, or is the design still under discussion and not firm enough to be on roadmap?
eleanorjboyd commentedon Sep 23, 2024
Coverage has been implemented and is merged so you can try it now on the pre-release of the python extension!
AlexanderPodorov commentedon Sep 23, 2024
Eleanor Boyd (@eleanorjboyd) , Hi, I've upgraded Python extension to

v2024.15.2024091301(pre-release), but I don't see "Run with coverage" option, I see only "Run test" and "Debug test"eleanorjboyd commentedon Sep 23, 2024
is your vscode version: ^1.94.0-20240913?
AlexanderPodorov commentedon Sep 23, 2024
This one:
I've run "Check for updates", but no updates available yet.
eleanorjboyd commentedon Sep 23, 2024
Ah ok sorry- I didn't realize it but the coverage change requires vscode insiders due to some extra dependencies. To do so you can download insiders here and it will work from there https://code.visualstudio.com/insiders/. Otherwise this will be part of the next release- so sometime next week you will be able to access it on stable vscode
AlexanderPodorov commentedon Sep 23, 2024
Thanks, sounds great! I'll wait for the next stable VSCode release and try it out.
msmitherdc commentedon Sep 23, 2024
Is this also functional for unittests via Django? I'm getting
coverage.py is installed.
eleanorjboyd commentedon Sep 26, 2024
Michael D. Smith (@msmitherdc) I will need to investigate coverage and Django together- thank you for surfacing this!
eleanorjboyd commentedon Sep 26, 2024
link to issue to track Django and Coverage together: #24199
AlexanderPodorov commentedon Oct 3, 2024
Eleanor Boyd (@eleanorjboyd) ,
I have upgraded to VSCode 1.94:
But I don't see "Run with coverage" option.

pytest-covandcoverageare installed.AlexanderPodorov commentedon Oct 3, 2024
For the future reference: I've switched to pre-release version of Python extension
v2024.17.2024100202 (pre-release)and it works great!captianboy7 commentedon Oct 4, 2024
I have switched to the pre-release version of Python extension v2024.17.2024100202 (pre-release) but still getting the error while running with coverage
eleanorjboyd commentedon Oct 4, 2024
And you don't override any variables? This message is a sign we can't find a env var we set to use for communication:
UNITTEST ERROR: TEST_RUN_PIPE is not set at the time of unittest trying to send data. Please confirm this environment variable is not being changed or removed as it is required for successful test discovery and execution
Secondly does it work with regular run and discovery? Both of these use the same TEST_RUN_PIPE so im surprised you can get those to work and not coverage
captianboy7 commentedon Oct 7, 2024
The terminal command for coverage works fine , and also my tests are been discovered in VS code. Also, the Run Tests button component in the testing works fine, but Run Tests with coverage runs all the tests but at the end fails with above error .
captianboy7 commentedon Oct 7, 2024
Now if you try in either the released version (v2024.16.0) or pre-released version (v2024.17.0) . This error is coming even when the test are sucessful
thomthom commentedon Jan 3, 2025
I just tested out "Run With Coverage" on my python project. I have the sources for my app in a sub-folder so my
coveragerccontains:However, when I use Run With Coverage it appear to inject
--cov=.which in turn overrides mysourceconfig. The result of that is that coverage picks up python all python files from the root of my project, not just limited to./myapp.I've not found any way around for this. Is it a bug? Or have I missed a configuration?
eleanorjboyd commentedon Jan 6, 2025
See this section of the docs
https://code.visualstudio.com/docs/python/testing
thomthom commentedon Jan 7, 2025
I found that when I had
--covargument I wasn't able to debug my tests. No breakpoints would catch. That's why I was looking for separate arguments between doing a normal test run and running tests with coverage.Not sure why the debugger wouldn't break when
--covwas used though, bug?eleanorjboyd commentedon Jan 7, 2025
the debugger doesn't work with coverage- it is just a general design problem as the two interfere. Understandable - hm let me think about how I could enable coverage without adding cov=. to make sure your args are not overwritten
eleanorjboyd commentedon Jan 7, 2025
Thomas Thomassen (@thomthom) can you open another issue and we can move the conversation there so I can address it specifically? And if you have a suggestion on the above problem of triggering discovery with pytest-cov without overwritten exisiting args let me know, thanks!