-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Debugger doesn't stop at breakpoints with pytest if pytest-cov is used #693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Note that the test is executed correctly. Even the "run test"/"debug test" button on each test executes correctly this individual test. |
@lmazuel apologies for the delay. |
Hmm, looks like we're not the only ones having trouble with debugging + pytest + coverage (https://www.jetbrains.com/help/pycharm/run-debug-configuration-py-test.html) I've tried passing in the flag I guess we could try to determine if Pytest-cov is installed or not. |
@lmazuel |
That's ok :). And I like the fact you open a documentation issue ;) |
@DonJayamanne I don't really like having to edit my workspace settings any time I want to switch back and forth between generating coverage and debugging. |
Thanks for the --no-cov trick ! Since I don't know how to develop VS Code plugins, I will use the trick for now :-) |
I suspect Following @justfalter's suggestion, I'd like to suggest another scheme for First, I think it's better off that the - python.unitTest.*
+ python.testing.* Second, I'd suggest instead implementing new settings namespaces fpr debug mode. These would be Ref: |
@limonkufu Put simply, there's no fix. Think about it this way:
There's no straightforward (and maintainable) way that the coverage tracker can know if the parts of your code that the debug terminal invoked should count towards coverage or not. The coverage frameworks disable breakpoints so that they can get accurate coverage reporting. It's for this reason that I suggested a new |
@zevisert thanks for explaining it clearly, I didn't understand it before,
if this is beginner friendly to this repo, I would like work on in. I'll
investigate a little bit thanks
…On Thu, 18 Mar 2021 at 03:50, Zev Isert ***@***.***> wrote:
@limonkufu <https://github.com/Limonkufu> Put simply, there's no fix.
Think about it this way:
1. Coverage is enabled and tests are run in debug mode
2. A breakpoint is hit and the program is paused
3. You run a command in the debug terminal that calls parts of your
code
There's no straightforward (and maintainable) way that the coverage
tracker can know if the parts of your code that the debug terminal invoked
should count towards coverage or not. The coverage frameworks disable
breakpoints so that they can get accurate coverage reporting. It's for this
reason that I suggested a new settings.json namespace above so that we
can specify different arguments for test debugging (i.e. with coverage
disabled)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#693 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2LFHAPTYINQU53NEOMDRTTEFZ75ANCNFSM4EO7DNXA>
.
|
for those coming to this thread, i have a solution that may work for some people. it involves moving your pytest args into pytest.ini within your project, setting up two tasks to sed and un-sed the coverage args, and adding these tasks to your launch.json. sample pytest.ini (this is for a django project):
tasks in tasks.json that use sed to overwrite the pytest.ini:
launch.json for debug tests:
slightly annoying solution as it pops open a task window in the terminal, but hey, it works. switch in your own pytest args, or if its only coverage, you can use sed to just comment out the line. |
I don't suppose there is a way to throw an error when this happens? Preferably a descriptive one, but any error would be helpful. The docs are appreciated, but since the debugger failure is silent, I wasn't sure if ignoring breakpoints in tests was the intended behavior or not (much less whether coverage should be something I Google docs on). |
I use an alternative to @dferrante 's solution above, which seems to be seamless inside the VSCode IDE for In
And then in
When you press the "Debug Test" button in the testing panel or by right-clicking on a test itself, VSCode executes this task which just turns off all coverage for that run. No need to switch between configurations or altering config arguments on the fly. Note this may only work for fairly new versions of VSCode - I'm on 1.60. |
Wouldn't the cleanest solution be for VSCode to automatically disable code coverage when a test is run in debug mode? User side you would see no code coverage when you run tests in debug but code coverage appear fine if you run without debug. That would be pretty clean and painless for the two scenarios (rather than having to fuss with run settings and env variables). |
seams like a good idea to me |
Just commenting that this is still a pain in the bum. I want to believe that @AlexanderWells-diamond's answer works because it's the only suggestion with a reasonable level of difficulty/complexity, but it doesn't for me. My only working solution is to uninstall pytest-cov and modify my setup.cfg when debugging. Here's my workspace configuration.
Here's setup.cfg.
|
For some reason it stops at manually set breakpoints for me, but not if an error is raised. So, a silly workaround (at least for me) has been to let it run until it errors out, track down the relevant line, and set a breakpoint on it. Obviously not a great solution for long-running tests, or when the same function gets called multiple times before the error occurs. |
Its something in vscode. If you right-click your test in "testing" then select Debug from the menu it works fine and you can hit your breakpoints in "testing". The debug "button" on the test does not allow the process to stop on a breakpoint. |
@ericchansen seems to me that you are specifying launch configuration in On a side note, it would be nice if these launch settings could be parsed from |
@skilkis could you include an example of a |
@sgbaird here is the {
"version": "0.2.0",
"configurations": [
{
// Disable cov to allow breakpoints when launched from VS Code Python
"name": "Python: Debug Tests",
"type": "python",
"request": "launch",
"program": "${file}",
"purpose": ["debug-test"],
"console": "internalConsole",
"justMyCode": false,
"presentation": {
"hidden": true
},
"env": {
"PYTEST_ADDOPTS": "--no-cov"
}
}
]
}
EDIT: Original fix was provided by @AlexanderWells-diamond in the answer above |
@skilkis I use multi-root workspaces. I can confirm that debugging in 1.68.0-insider doesn't work with this workspace (see below). You can see that all of the relevant settings in the launch section of this multi-root workspace are the same as @skilkis's settings.
The only way to make the debugger work is to remove If it works in a |
@ericchansen I've created a minimal reproduction of your configuration and it also does not work for me. The code I used to test it is located at skilkis/vscode_python_pytest_multi_root_breakpoint_issue. Would you mind testing the After this I believe we can make a feature request to have support for |
@skilkis I tested this with
vs.
Both options show up in the "Run and Debug" sidebar and work as expected if selected. But if I comment out the contents of You can recreate this with any tests. |
This is actually worse than it seems at first blush. Not only will running with coverage enabled fail to respect breakpoints in PyCharm, but I've also found it causes manually inserted |
This is what I use under
As mentioned in the comment in the setting, I make sure I have I don't use "Run and Debug" a lot (but I do use a lot of "Testing") and don't remember having an issue with this there so I don't know if I already had the workaround in place or I just didn't hit it. PS.: In my settings I also make use of |
Closing as we do not plan to implement this work. |
Environment data
VS Code version: 1.19.3
Python Extension version: 2018.1.0
Python Version: 3.6.2
OS and version: Windows 10 latest update
Actual behavior
My initial setup has this setup.cfg file:
This adds automatically a "--cov" to every "pytest" call, but prevents VSCode to stop at breakpoints. If I remove the file (or at least the --cov), I get back my breakpoints stop.
I changed my setup to put that in my Travis file instead, but I feel like this should work :/
Expected behavior
I should be able to have this file (and coverage) and debug at the same time.
Steps to reproduce:
The text was updated successfully, but these errors were encountered: