Repository navigation
Read test debug configuration from settings not just launch.json #532
Description
Issue Type: Bug
Behaviour
Expected vs. Actual
Adding this to my .vscode/launch.json allows me to use breakpoints in third-party libraries when debbuging unit tests:
{
"name": "Debug Unit Test",
"type": "python",
"request": "test",
"justMyCode": false
}
I expect that adding the same to the launch section of my workspace settings would produce the same behaviour but this is not true.
Steps to reproduce:
- Add the above debug config to your
.vscode/launch.jsonfile. - Add a breakpoint to a third party tool.
- Debug a unit test that calls the third party code and the debbuger will stop in the breakpoint.
- Delete the
.vscode/launch.jsonfile. - Add the above debug config in your workspace settings.
- Add a breakpoint to a third party tool.
- Debug a unit test that calls the third party code and the debbuger will skip the breakpoint.
Diagnostic data
- Python version (& distribution if applicable, e.g. Anaconda): 3.10.0
- Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Venv
- Value of the
python.languageServersetting: Default
User Settings
defaultLS: {"defaultLSType":"Pylance"}
downloadLanguageServer: true
envFile: "<placeholder>"
venvPath: "<placeholder>"
venvFolders: "<placeholder>"
condaPath: "<placeholder>"
pipenvPath: "<placeholder>"
poetryPath: "<placeholder>"
languageServer: "Pylance"
linting
• enabled: true
• cwd: "<placeholder>"
• Flake8Args: "<placeholder>"
• flake8Enabled: true
• flake8Path: "<placeholder>"
• lintOnSave: true
• banditArgs: "<placeholder>"
• banditEnabled: false
• banditPath: "<placeholder>"
• mypyArgs: "<placeholder>"
• mypyEnabled: true
• mypyPath: "<placeholder>"
• pycodestyleArgs: "<placeholder>"
• pycodestyleEnabled: false
• pycodestylePath: "<placeholder>"
• prospectorArgs: "<placeholder>"
• prospectorEnabled: false
• prospectorPath: "<placeholder>"
• pydocstyleArgs: "<placeholder>"
• pydocstyleEnabled: false
• pydocstylePath: "<placeholder>"
• pylamaArgs: "<placeholder>"
• pylamaEnabled: false
• pylamaPath: "<placeholder>"
• pylintArgs: "<placeholder>"
• pylintPath: "<placeholder>"
sortImports
• args: "<placeholder>"
• path: "<placeholder>"
formatting
• autopep8Args: "<placeholder>"
• autopep8Path: "<placeholder>"
• provider: "autopep8"
• blackArgs: "<placeholder>"
• blackPath: "<placeholder>"
• yapfArgs: "<placeholder>"
• yapfPath: "<placeholder>"
testing
• cwd: "<placeholder>"
• debugPort: 3000
• nosetestArgs: "<placeholder>"
• nosetestsEnabled: undefined
• nosetestPath: "<placeholder>"
• promptToConfigure: true
• pytestArgs: "<placeholder>"
• pytestEnabled: true
• pytestPath: "<placeholder>"
• unittestArgs: "<placeholder>"
• unittestEnabled: false
• autoTestDiscoverOnSaveEnabled: true
terminal
• activateEnvironment: true
• executeInFileDir: "<placeholder>"
• launchArgs: "<placeholder>"
experiments
• enabled: true
• optInto: []
• optOutFrom: []
insidersChannel: "off"
tensorBoard
• logDirectory: "<placeholder>"
Extension version: 2022.2.1924087327
VS Code version: Code 1.65.2 (c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1, 2022-03-10T15:36:26.048Z)
OS version: Linux x64 4.14.240
Restricted Mode: No
Activity
luabud commentedon Mar 25, 2022
Hi Roberto Lapuente (@ElPincheTopo), the launch.json configuration has changed for debugging tests (see https://code.visualstudio.com/docs/python/testing#_debug-tests). Can you try the configuration below?
And just out of pure curiosity, what is the reason behind using it on your workspace configuration rather than launch.json?
karthiknadig commentedon Mar 29, 2022
We currently only read this from the launch.json. We could expand the scope of where we read it from, but that has some things that we have not decided yet. Like how we handle multiple test configurations, which one takes priority, etc.
[-]Debug config for unit tests not working when launch config is stored in the workspace settings[/-][+]Read test debug configuration from settings not just launch.json[/+]ElPincheTopo commentedon Mar 29, 2022
Thanks for the hint Luciana Abud (@luabud). It's good to know that that has changed, but it still behaves on the same way as my original example.
My original description might have not been super clear. I'm storing my workspace settings in a
PROJECT.code-workspacefile outside of the repository. I use this in some projects to be able to have multiple folders in the same workspace, and if I'm already putting my settings in there it makes sense to put all the settings in there unless I need to override something for one of the folders in the project.Karthik Nadig (@karthiknadig) I think that test configurations defined in the Folder settings (
.vscode/launch.json) should take precedence, then the ones on the Workspace settings (PROJECT.code-workspace) and then the ones in the User settings. I think that this would be consistent with the way all the other settings get applied in vscode, which is why I expected this to work.Currently, if you have more than one test configuration defined in your
launch.jsonthe first one gets used and the rest are ignored, so making this change would preserve the existing behavior but expand the places the config can be read from to make it consistent with other settings in vscode.MetRonnie commentedon Apr 25, 2022
It doesn't help that the command
Open 'launch.json'in the command palette just opens settings.json if you haven't got a launch.json. That makes you think there would be no difference between where you add a configurationcoretl commentedon Nov 8, 2022
I have the same workflow, vscode settings in a workspace settings rather than in the repository, so I'd love to see a solution to this. I found this issue after reading microsoft/vscode-python#693 and the last comment in that thread seems to be about this issue, so commenting to link the two.
7 remaining items