Skip to content
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

Add a button to remove tests from testing panel. Or do not add tests from standard libraries #3262

Open
nursik opened this issue Mar 18, 2024 · 2 comments
Labels
go-test issues related to go test support (test output, test explorer, ...)

Comments

@nursik
Copy link

nursik commented Mar 18, 2024

Is your feature request related to a problem? Please describe.
If you open any test file from standard library, two test suits (cmd and std) will be added to testing panel. All extension commands related with testing will not run these tests. However, Test: Run All Tests runs these tests and it is impossible to cancel it.

image
Describe the solution you'd like

  • Add a button to remove tests from panel
  • Do not add tests from standard libraries by default

Describe alternatives you've considered
Hide them or reopen an editor.

Additional context
I could not find an option to refresh list of tests for the package or a command to remove tests from panel.

@gopherbot gopherbot added this to the Untriaged milestone Mar 18, 2024
@findleyr findleyr added the go-test issues related to go test support (test output, test explorer, ...) label Mar 18, 2024
@findleyr
Copy link
Contributor

It sounds like we should be automatically refreshing tests in the explorer.

I think @hyangah and @firelizzard18 were discussing revamping test discovery for the test explorer, but I'm not sure of the current status of that work. This is yet another datapoint to consider.

@firelizzard18
Copy link
Contributor

@findleyr I have a CL open and waiting for review that adds test discovery to gopls, and one for vscode-go that switches the discovery backend to gopls (as a WIP, pending the first CL).

This is an interesting case. Test discovery is driven in two ways: 1) when you open a workspace, the host (vscode) asks the extension (vscode-go) for test roots and the extension returns a list of roots (workspaces) - the host pulls tests; 2) when you open a test file, the extension looks for tests and pushes those to the host. So here the extension is pushing tests when the file gets loaded.

I don't want to do a lot of work on this until the switch to gopls has gone through. Also I've been feeling for a while that the extension's test discovery code (my code) needs refactoring. Currently (with those two CLs), gopls is pull only, as in the extension pulls test data from gopls; gopls does not push any test stuff to the extension. It's possible we could add some push logic/notifications from gopls, especially if Microsoft defines some LSP-type protocol for tests. But unless and until that happens, ultimately the extension is deciding what to look for.

I'm not sure how to handle this scenario. I want to unify all the test code (assuming I have the time). If that happens or if you want the test explorer features, test items have to be pushed - I don't think the host allows 'transient' test items. One possibility is a setting - "Don't discover test items for files outside the current workspace". Or we could provide some way to unload test roots. Or "Delete test items for files outside the current workspace as soon as those files are closed". Ultimately this is a UX question and that's not one of my strengths.

Side note, in this scenario if we're showing the test items (even just transiently), I think I'd like the root item to be something like go1.22.1. Though from an implementation POV I think I'll just stick to whatever gopls does, as in I'll ask gopls what the workspace root is for the file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
go-test issues related to go test support (test output, test explorer, ...)
Projects
None yet
Development

No branches or pull requests

5 participants