microsoft / microsoft/vscode

Testing with coverage should respect Coverage.py configuration

Open
#326,404 0 comments 0 reactions 1 assignee Claimed by @eleanorjboyd View on GitHub
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

## Description

When running Python tests with coverage from VS Code’s Testing view, the Python extension constructs the following pytest command:

```
Running pytest with args: [
'-p',
'vscode_pytest',
'--rootdir=/Users/kamil/Projects/reactor',
'--cov=.',
'--cov-branch',

]
```

The hard-coded `--cov=.` and `--cov-branch` arguments override or duplicate settings that should come from the project’s Coverage.py configuration.

For example, my project has a `.coveragerc` file containing:

```ini
[run]
branch = True
source =
project/

[report]
show_missing = True
skip_covered = True
skip_empty = True
```

In particular, `source = project/` is not respected because VS Code explicitly passes `--cov=.`. As a result, coverage run through the Testing UI can differ from coverage run through the project’s normal pytest/Coverage.py configuration.

## Expected behavior

Running tests with coverage from the Testing view should allow Coverage.py and `pytest-cov` to load their settings from `.coveragerc`, `.coveragerc.toml`, `pyproject.toml`, `setup.cfg`, or `tox.ini`.

Ideally, VS Code would run pytest with `--cov` without supplying a source value and would not add `--cov-branch` automatically. Alternatively, the automatically added coverage arguments should be configurable, including the ability to disable `--cov=.` and `--cov-branch`.

## Actual behavior

VS Code unconditionally adds `--cov=.` and `--cov-branch`. This changes the configured coverage source and makes the Testing UI’s coverage behavior inconsistent with command-line execution.

## Motivation

Coverage settings are typically maintained in the project’s shared configuration so they remain consistent across local development, CI, and editor integrations. The VS Code Testing integration should defer to that configuration instead of imposing its own source and branch settings.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.