You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of the tests (via unittest) I want to run locally require specific env variables. These tests also run in CI with different variables, so I would like to set them only locally in vscode. The "Debug Tests" launch.json feature allows me to do that, but only when debugging. I think a "Run Tests" option in launch.json would be really helpful for this.
ronif Ah! Just realized this is for "Run Tests" specifically. The previous comment applies specifically to debugging. We should make sure that if there is a test configuration in launch.json we should just run it under the debugger with noDebug set to true.
Thank you for the suggestion! We have marked this issue as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.
It triggers WARNING: Coverage disabled via --no-cov switch! (that cannot be fully disabled with --disable-pytest-warnings or -p no:warnings). And you cannot see a green tick near a passed test only a gray question mark.
It does not work if you are trying to overwrite PYTEST_ADDOPTS in .env, pytestArg must be used instead of .env . Somewhy the content of .env cannot be overwritten.
So this is currently just working for test debugging, but not for just running the test with the Testing-Ribbon, right?
{
"name": "Test config",
"type": "python",
"request": "test", // <--- this is the magic
"env": {
// add env variables here
}
}
Do I have any other chance to set environment variables before running all tests with the Testing-Ribbon? I'm using Python with Pytest and can now debug tests with the Testing-Ribbon from VSCode, but the config seems not to be used when just running the test, without debugging.
For run scenario, the best option would be set up all of the environment variables you need in a terminal and then launch VS code from there using code . or code <project-dir>.
We are currently working on improving the test adapter #17242, after that we should be in a better place to tackle these scenarios.
Our team are moving to vscode because of the dev-container support and this is the biggest sticking point they have when moving from pycharm - any update?
My goal is to have a debugging session where I can use "debug test" from a test and be able to set breakpoints in library code.
Adding the "purpose" option helps. However the behavior between regular debugging and with this is different.
When at a breakpoint it doesn't get to the right point in the call stack automatically.
Activity
karthiknadig commentedon May 22, 2020
karthiknadig commentedon May 22, 2020
ronif Ah! Just realized this is for "Run Tests" specifically. The previous comment applies specifically to debugging. We should make sure that if there is a test configuration in launch.json we should just run it under the debugger with
noDebugset totrue.karthiknadig commentedon May 22, 2020
Thank you for the suggestion! We have marked this issue as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.
0az commentedon May 27, 2020
Does this apply to the
envFilekey?abid-mujtaba commentedon Mar 4, 2021
This feature will also allow one to use
preLaunchTaskwhile running tests, not just while debugging.NickVeld commentedon Mar 31, 2021
Continuing the previous comment:
... and will also allow one to set in a distinct configuration PYTEST_ADDOPTS for the coverage counting with custom arguments.
Now the only option at least to enable coverage and do not break debugging exists. It is to add --no-cov to the debug configuration : https://code.visualstudio.com/docs/python/testing#_pytest-configuration-settings
Some troubles connected with current approach:
WARNING: Coverage disabled via --no-cov switch!(that cannot be fully disabled with--disable-pytest-warningsor-p no:warnings). And you cannot see a green tick near a passed test only a gray question mark.SebastianB12 commentedon Jan 19, 2022
So this is currently just working for test debugging, but not for just running the test with the Testing-Ribbon, right?
Do I have any other chance to set environment variables before running all tests with the Testing-Ribbon? I'm using Python with Pytest and can now debug tests with the Testing-Ribbon from VSCode, but the config seems not to be used when just running the test, without debugging.
karthiknadig commentedon Jan 19, 2022
For run scenario, the best option would be set up all of the environment variables you need in a terminal and then launch VS code from there using
code .orcode <project-dir>.We are currently working on improving the test adapter #17242, after that we should be in a better place to tackle these scenarios.
SebastianB12 commentedon Jan 19, 2022
Another solution I found, was just to add an python.envFile to the settings.json:
not ideal, because I guess that is now also setting/overwriting the envs for normal debugging, which I defined before in the launch.json file?
boatcoder commentedon Oct 6, 2022
In 2022, this appears to no longer function:
Pytest launches without any of these options added (and 10 processes are not created, verified with ps -ax)
karthiknadig commentedon Oct 6, 2022
Mark Jones (@boatcoder) This is now changed a bit, try this:
ViswanathB commentedon Jan 9, 2023
"purpose": ["debug-test"]is the key.NiKeYiGuN commentedon Apr 13, 2023
what do I need to do for unittest?
moleary-gsa commentedon Jul 14, 2023
Our team are moving to vscode because of the dev-container support and this is the biggest sticking point they have when moving from pycharm - any update?
rvanlaar commentedon Jun 14, 2024
My goal is to have a debugging session where I can use "debug test" from a test and be able to set breakpoints in library code.
Adding the "purpose" option helps. However the behavior between regular debugging and with this is different.
When at a breakpoint it doesn't get to the right point in the call stack automatically.
What am I missing here?