Provide separate configurations for running tests with coverage

[thomthom]

Following up on conversion in this thread:
#22827 (comment)

I found that when I had --cov argument 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 --cov was used though, bug?

I keep running into this.

I would to configure the coverage arguments when running tests with coverage so I can narrow down the scope of what is checked for coverage. But I don't want to add arguments that enables coverage in normal test runs. (Which conflicts when I'm debugging tests.)

#22827 (comment)

I just tested out "Run With Coverage" on my python project. I have the sources for my app in a sub-folder so my coveragerc contains:

[run]
source = myapp
omit = myapp/tests/*

However, when I use Run With Coverage it appear to inject --cov=. which in turn overrides my source config. 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?

What I think would work is a configuration setting for what vscode-python injects when running with coverage. The default is --cov=., but if we can override that it would help.

Maybe something like

{
  "python.testing.pytestCoverageArgs": "--cov=mysources", // Defaulting to "--cov=."
}

[eleanorjboyd]

added this request to an overarching issue about custom configs for testing: #21845

[eleanorjboyd]

@cwebster-99 since we haven't had movement on our custom configs for testing, should we consider just adding this seperately?

[github-actions]

Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

[james-crow]

This gets my vote, would be great to have this flexibility, and is particularly useful in monorepo environments.