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
{{ message }}
Repository navigation
Option to disable "run test | debug test" links #10898
just a minor nit -- is there any way to disable these two links?
When writing tests, these lines show up when the code is OK, but they disappear every time there's a syntax error - effectively every time I save a _test.go file that doesn't compile.
The showing up / hiding causes the code to jump up and down and it gets too much of my attention and slows me down.
The code jumping up and down while I type kind of makes me seasick. Is there any way to disable just this one codelens for Python tests (or tests in general, for that matter)? There's always:
"editor.codeLens": false
but that disables all code lenses everywhere, which is less than ideal.
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.
I came here to file this same bug, but searched first and found this. Fairly annoying when you have more than 2-3 tests because the code at the bottom jumps by the number of tests plus the number of classes. So if you have one class with 15 tests, it'll jump by 16 lines every time these things appear/disappear.
Maybe some would argue that the source class should be simplified for less tests or something, but I don't think 15 tests is unreasonable.
I'd prefer to keep these codelens adornments, as they're kind of useful, if there's a way to stop this jumping behavior while coding tests. But if the choice is have them disabled entirely (e.g. "python.testing.codeLens" or something) or use the setting to disable all codelens in the project (using editor.codeLens), I'd happily disable just these python unittest codelens adornments if the feature was available.
Reacted by G Fedewa, Ross Richardson, Max Klein, smcoll, Jan Moravec and Silas Alberti
I also came here looking for a way to turn off the lens. I run tests for most projects in the terminal in a docker environment, so the lens is just taking up space. It would be useful to have an option to hide it.
We can add a setting called "python.testing.codeLensesEnabled" that can be true by default, but will have code lenses disabled if set to false.
I think it may make sense to have it in the User scope only, but I don't think it'd be bad to have it in the Workspace scope either.
Luciana Abud (@luabud) I guess that means it's difficult to make it stop jumping around so we can keep them?
Assuming that's the case, I'd agree with the User scope thing because this seems to pretty clearly be a personal preference rather than related to a specific project. Although I can't imagine who isn't bothered by the text jumping around as you edit more than 3-4 tests.
Luciana Abud (@luabud) I guess that means it's difficult to make it stop jumping around so we can keep them?
Assuming that's the case, I'd agree with the User scope thing because this seems to pretty clearly be a personal preference rather than related to a specific project. Although I can't imagine who isn't bothered by the text jumping around as you edit more than 3-4 tests.
I just wanted to echo this. I don't mind having the adornments/code lens there, it's the code bobbing up and down that could use a fix.
Perhaps another idea would be to put the adornment in-line with the function declaration. Either to the left or the right of the text. Having it take up a brand new line seems to be part of the issue.
I just want to +1 this. I am teaching python and decided to use VSCode because it is very simple to install and use and works for many languages but working with tests is frustrating because students cannot follow what I do due to all these jumps. I have to disable code lenses but it is not ideal.
I am not sure how PyCharm does it, but in there you get a play button to the left of the tests that does not move ever, it does not even matter if pytest, unittests or whatever testing frame you use can discover the tests. They are just recognized. No matter what. If there is an import error (which causes the discovered test disappear due to pytest not being able to find them) vscode fails to recognize the test, this does not happen in pycharm.
Not sure why the code lenses disappear so often but maybe, if you the same discovery procedure as done in pycharm cannot be replicated, you might want to consider to put the codelense somewhere else, like inline with the test as @1studlyman mentioned.
Reacted by Jesse Pangburn, Silas Alberti and Christopher Collett
This isn't 100% related, but there are actually a whole bunch of similar issues caused by VSCode saving the file you're actively editing while it has an error.
You stop typing for 3 seconds while there's a syntax error in your code? Suddenly you get a message "Test discovery failed", the code shifts upwards because the code lens thingies are gone, all the red and yellow squiggles created by the linter disappear, basically any tool that analyzes your code stops working. And then you continue typing, and suddenly everything starts working again. And then you type some more, and it breaks again. This constant back-and-forth is honestly infuriating.
Can't wait to see this fix when it's released! Thanks a lot Karthik Nadig (@karthiknadig) !!! I see it's merged, so we just have to wait until the next update :-)
Jesse Pangburn (@jpangburn) you can also try it out on the Insiders program! You can go to View > Command Palette... and run "Python: Switch to Insiders Weekly Channel". After it finishes downloading the new version you will need to reload the window, but after that it should work 😊
You might need to also update VS Code to version >= 1.59.0
I'm happy to bring (an option for) the classic codelenses back in the native testing implementation, though thus far it seems most people have been happy with the gutter decorations. Interested to hear thoughts on other UI.
I'm happy to bring (an option for) the classic codelenses back in the native testing implementation, though thus far it seems most people have been happy with the gutter decorations. Interested to hear thoughts on other UI.
Connor Peet (@connor4312)Luciana Abud (@luabud) Would love the Code Lens options back, maybe I'd get used to the gutter decorations but it's a lot easier for me to just click "run test" than to right click and parse the contextual menu.
My bigger issue is the organization in the sidebar. I think the full path text is distracting, and I preferred the previous UI of showing only the Folder and class names as I navigated into tests in other directories/modules. Showing the full paths doesn't seem to add anything, especially since clicking on any one test takes you in the editor to the code for that test anyway.
I realize that's out of scope for this closed issue, I am happy to open some other issues on the Test UI. I tried to turn Insiders back on to examine the UI again more closely just now, but this led to discovery failing for one subfolder of my workspace, which appears to have broken discovery for all the other folders in my workspace so none of my tests were available and the UI issue became secondary. I'll see if I can reproduce the discovery issue in a test repo tonight and open an issue if I can.
Would love the Code Lens options back, maybe I'd get used to the gutter decorations but it's a lot easier for me to just click "run test" than to right click and parse the contextual menu.
The default left click action on the decorations is to run the test, though you can change that with the testing.defaultGutterClickAction setting.
My bigger issue is the organization in the sidebar. I think the full path text is distracting, and I preferred the previous UI of showing only the Folder and class names as I navigated into tests in other directories/modules. Showing the full paths doesn't seem to add anything, especially since clicking on any one test takes you in the editor to the code for that test anyway... this led to discovery failing for one subfolder of my workspace, which appears to have broken discovery for all the other folders in my workspace so none of my tests were available and the UI issue became secondary
Activity
brettcannon commentedon Apr 1, 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.
jpangburn commentedon Apr 15, 2020
I came here to file this same bug, but searched first and found this. Fairly annoying when you have more than 2-3 tests because the code at the bottom jumps by the number of tests plus the number of classes. So if you have one class with 15 tests, it'll jump by 16 lines every time these things appear/disappear.
Maybe some would argue that the source class should be simplified for less tests or something, but I don't think 15 tests is unreasonable.
I'd prefer to keep these codelens adornments, as they're kind of useful, if there's a way to stop this jumping behavior while coding tests. But if the choice is have them disabled entirely (e.g. "python.testing.codeLens" or something) or use the setting to disable all codelens in the project (using editor.codeLens), I'd happily disable just these python unittest codelens adornments if the feature was available.
frediy commentedon Apr 28, 2020
I also came here looking for a way to turn off the lens. I run tests for most projects in the terminal in a docker environment, so the lens is just taking up space. It would be useful to have an option to hide it.
luabud commentedon May 14, 2020
We can add a setting called
"python.testing.codeLensesEnabled"that can betrueby default, but will have code lenses disabled if set tofalse.I think it may make sense to have it in the User scope only, but I don't think it'd be bad to have it in the Workspace scope either.
jpangburn commentedon May 14, 2020
Luciana Abud (@luabud) I guess that means it's difficult to make it stop jumping around so we can keep them?
Assuming that's the case, I'd agree with the User scope thing because this seems to pretty clearly be a personal preference rather than related to a specific project. Although I can't imagine who isn't bothered by the text jumping around as you edit more than 3-4 tests.
pachecoke commentedon May 14, 2020
I just wanted to echo this. I don't mind having the adornments/code lens there, it's the code bobbing up and down that could use a fix.
jdunns commentedon May 19, 2020
Perhaps another idea would be to put the adornment in-line with the function declaration. Either to the left or the right of the text. Having it take up a brand new line seems to be part of the issue.
Thanks!
AAraKKe commentedon Jun 5, 2020
I just want to +1 this. I am teaching python and decided to use VSCode because it is very simple to install and use and works for many languages but working with tests is frustrating because students cannot follow what I do due to all these jumps. I have to disable code lenses but it is not ideal.
I am not sure how PyCharm does it, but in there you get a play button to the left of the tests that does not move ever, it does not even matter if pytest, unittests or whatever testing frame you use can discover the tests. They are just recognized. No matter what. If there is an import error (which causes the discovered test disappear due to pytest not being able to find them) vscode fails to recognize the test, this does not happen in pycharm.
Not sure why the code lenses disappear so often but maybe, if you the same discovery procedure as done in pycharm cannot be replicated, you might want to consider to put the codelense somewhere else, like inline with the test as @1studlyman mentioned.
12 remaining items
Aran-Fey commentedon Apr 22, 2021
This isn't 100% related, but there are actually a whole bunch of similar issues caused by VSCode saving the file you're actively editing while it has an error.
You stop typing for 3 seconds while there's a syntax error in your code? Suddenly you get a message "Test discovery failed", the code shifts upwards because the code lens thingies are gone, all the red and yellow squiggles created by the linter disappear, basically any tool that analyzes your code stops working. And then you continue typing, and suddenly everything starts working again. And then you type some more, and it breaks again. This constant back-and-forth is honestly infuriating.
karthiknadig commentedon Jul 29, 2021
this should be addressed by #16769
This is the new UI:

jpangburn commentedon Aug 6, 2021
Can't wait to see this fix when it's released! Thanks a lot Karthik Nadig (@karthiknadig) !!! I see it's merged, so we just have to wait until the next update :-)
luabud commentedon Aug 6, 2021
Jesse Pangburn (@jpangburn) you can also try it out on the Insiders program! You can go to View > Command Palette... and run "Python: Switch to Insiders Weekly Channel". After it finishes downloading the new version you will need to reload the window, but after that it should work 😊
You might need to also update VS Code to version >= 1.59.0
astrowonk commentedon Aug 8, 2021
Sigh. I really preferred the old codelens look, and the old organization of Tests in the sidebar, and do not like the new UI for tests at all.
luabud commentedon Aug 9, 2021
Marcos Huerta (@astrowonk) would you mind explaining more about what you don't like about the new UI?
(cc Connor Peet (@connor4312))
connor4312 commentedon Aug 9, 2021
I'm happy to bring (an option for) the classic codelenses back in the native testing implementation, though thus far it seems most people have been happy with the gutter decorations. Interested to hear thoughts on other UI.
astrowonk commentedon Aug 9, 2021
Connor Peet (@connor4312) Luciana Abud (@luabud) Would love the Code Lens options back, maybe I'd get used to the gutter decorations but it's a lot easier for me to just click "run test" than to right click and parse the contextual menu.
My bigger issue is the organization in the sidebar. I think the full path text is distracting, and I preferred the previous UI of showing only the Folder and class names as I navigated into tests in other directories/modules. Showing the full paths doesn't seem to add anything, especially since clicking on any one test takes you in the editor to the code for that test anyway.
I realize that's out of scope for this closed issue, I am happy to open some other issues on the Test UI. I tried to turn Insiders back on to examine the UI again more closely just now, but this led to discovery failing for one subfolder of my workspace, which appears to have broken discovery for all the other folders in my workspace so none of my tests were available and the UI issue became secondary. I'll see if I can reproduce the discovery issue in a test repo tonight and open an issue if I can.
connor4312 commentedon Aug 9, 2021
The default left click action on the decorations is to run the test, though you can change that with the
testing.defaultGutterClickActionsetting.Karthik Nadig (@karthiknadig)
astrowonk commentedon Aug 9, 2021
Connor Peet (@connor4312) Karthik Nadig (@karthiknadig) Opened #16902 on the test discovery issue. It doesn't seem related to failing imports but just perhaps a certain hierarchical folder structure.