Option to disable "run test | debug test" links

[telamonian]

I'm having the same issue as this guy from a while back on vscode-go, but with the Python extension:

Hi,

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.

[brettcannon]

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]

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]

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]

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.

[jpangburn]

@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]

@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.

[jdunns]

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]

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.

[luabud]

I guess that means it's difficult to make it stop jumping around so we can keep them?

That's correct. We rely on VS Code's APIs for the code lenses, I don't believe the extension is doing anything special to cause this "jumping around" behaviour. We were considering dropping off the code lenses but the feedback we receive is that a lot of people do like it and would prefer to have them on.

That said, we also have a test explorer with a run button that doesn't jump around 😅 the explorer shows up once tests are configured:

@AAraKKe I see that you mentioned that the code lenses disappear often. The original problem behind this issue was about the "jumping" behaviour of the code lenses, not that the extension failed to recognize tests. Your problem sounds like a separate bug, am I understanding it right?

[telamonian]

@AAraKKe I see that you mentioned that the code lenses disappear often. The original problem behind this issue was about the "jumping" behaviour of the code lenses, not that the extension failed to recognize tests. Your problem sounds like a separate bug, am I understanding it right?

@luabud These are related problems. As I type the contents of a given test, the test tends to cycle into/out of a state of valid/invalid syntax. Further, my vscode is set up to save files on loss of focus (I assume most people on this post have some similar form of autosave). Whenever the file gets saved while the test is valid, the codelens discovers the test and appears, and whenever the file gets saved while the test contains invalid syntax, the codelens loses the test and vanishes. Thus, the cycle of test discovery-loss-discovery appears to be what's causing the codelens to in turn cycle through appear-vanish-appear.

So one way to resolve the issue would be to be smarter/more lazy about striking tests off the discovered list. Eg, for the purpose of test discovery, maybe do a regexp for "class (Test\w*)" when invalid syntax is encountered, and then retain any previously existing tests that match.

[AAraKKe]

@luabud These are related problems. As I type the contents of a given test, the test tends to cycle into/out of a state of valid/invalid syntax. Further, my vscode is set up to save files on loss of focus (I assume most people on this post have some similar form of autosave). Whenever the file gets saved while the test is valid, the codelens discovers the test and appears, and whenever the file gets saved while the test contains invalid syntax, the codelens loses the test and vanishes. Thus, the cycle of test discovery-loss-discovery appears to be what's causing the codelens to in turn cycle through appear-vanish-appear.

Exactly this. I can add that I disabled the option to discover on save because the discovered triggered the run/debug lenses to appear and disappear. Even with the option disabled it keeps happening. This means that it is related with the fact that it can or cannot find the tests (no discover is being done) but with the file syntax being valid or not itself.

[CarloDePieri]

I can confirm that whenever the syntax is invalid those lenses disappears.

I would really appreciate a settings to turn them off, also because they kinda clash with other plugin lenses (test explorer ui python plugin, for example).

[Janickvw]

Did this get fixed? Writing tests is making me seasick with the code bobbing up and down.

[mmatrosov]

Just letting you guys know the issue is still very relevant. Jumping up-and-down code of tests is not cool.

[iivvoo]

I had these lenses tamed at some point (this issue was there 2 years ago as well), but they reappeared.

I might be missing something, but I think the setting below will disable it specifically for python (they work fine for me with golang, for example)

    "[python]": {
        "editor.codeLens": false
    }

But ideally the jumping should be fixed.

[AbdealiLoKo]

Came here for the same issue - the jumping was frustrating me causing misclicks when I am in a hurry. @iivvoo 's solution worked well for me - thanks!

[h-dub]

@iivvoo This works. TY!!

[oryon-dominik]

    "[python]": {
        "editor.codeLens": false
    }

unfortunately this deactivates all code lenses, even the useful ones. And I personally like my lenses a lot.

I'm also using the Extension: Python Test Explorer for Visual Studio Code, that has good (or better) code-lenses too. I could deactivate their lenses "Run" and "Debug", but I prefer them over the "Run Test" | "Debug Test" from the official extension.

A setting like python.testing.codeLens": true, would be awesome.

[wackazong]

Ok, just do it yourself. Go to the Microsoft Python extension source and open the file out/client/extension.js. In there you can remove the line that adds the code lenses to the registry. Remove the following piece of text, save the file, reload VSCode.

if(c)return[new r.CodeLens(i,{title:l(c.status)+s.Text.CodeLensRunUnitTest,command:s.Commands.Tests_Run,arguments:[void 0,a.CommandSource.codelens,e,{testFunction:[c]}]}),new r.CodeLens(i,{title:l(c.status)+s.Text.CodeLensDebugUnitTest,command:s.Commands.Tests_Debug,arguments:[void 0,a.CommandSource.codelens,e,{testFunction:[c]}]})];

Of course this is a hack which will not persist through updates and will probably not work with exactly the same string the next update. But you get my drift. You can also just search for CodeLensRunUnitTest, read the code and act accordingly.

[Christopher-Collett]

I want to say that this issue is still very relevant and a cause for great concern.

Adding a flag like python.testing.enableCodeLens would be a patch for the problem (and it would definitely be appreciated as an intermediate fix!)

A solution would be something similar to what @telamonian and @AAraKKe discussed. Discover tests that match the pattern that pytest and unittest search for, but don't "invalidate" the tests and cause the code lens to disappear because of a syntax, import or attribute error. Additionally, if a test has already been discovered and has the code lens floating above it, place an additional tag like Invalid Test next to Run Test | Debug Test instead of removing it if for whatever reason the test is no longer discoverable.

[Aran-Fey]

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]

this should be addressed by #16769

This is the new UI:

[jpangburn]

Can't wait to see this fix when it's released! Thanks a lot @karthiknadig !!! I see it's merged, so we just have to wait until the next update :-)

[luabud]

@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]

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]

@astrowonk would you mind explaining more about what you don't like about the new UI?

(cc @connor4312)

[connor4312]

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]

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.

@connor4312 @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]

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

@karthiknadig

[astrowonk]

@connor4312 @karthiknadig Opened #16902 on the test discovery issue. It doesn't seem related to failing imports but just perhaps a certain hierarchical folder structure.