x/tools/gopls: add CodeLens `Go to TestXxx`

[ShoshinNikita]

Env

gopls version: master (5397e65c)

Proposal

GoLand offers a Go to test shortcut (Ctrl+Shift+T) that allows users to jump to test definitions (if any) or create a new test:

I propose to add a similar feature to gopls. Initially, I was going to suggest to add a new command Go to TestXxx to the Source Action window (Alt+. in VSCode), mimicking GoLand. However, I think implementing it as a CodeLens would be more convenient: users can immediately see what functions have tests.

An MVP implementation can be found at https://go.dev/cl/696395. Examples of Go to TestXxx CodeLens for slices package (actually, Go to {Test|Example|Benchmark|Fuzz}Xxx):

Questions

1. I am not sure what algorithm should be used to match functions with their tests. A naive approach looks like this:

   1. Try to find test functions that match name exactly:
      • TestFoo for Foo
      • Test_foo for foo
      • TestBuffer_Bytes for (Buffer).Bytes
   2. Search with the capitalized first letter:
      • TestFoo for foo
      • TestBuffer_Bytes for (buffer).Bytes

   This algorithm should not have many false positives, but it fails to match TestReplaceGrow, TestReplacePanics, etc. with slices.Replace. We could use a prefix search like GoLand does, but I am not sure how to exclude TestDeleteFunc from matches for Delete:

   

2. Maybe it's worth implementing this feature both as CodeLens and Source Action?

   	Pros	Cons
   CodeLens	- obvious which functions have tests - requires only a single click	- requires a mouse click [0] - noisy when a function has many tests [1]
   Source Action	- easy to display all tests	- not obvious whether a function has tests - requires 3 actions: Alt+., move selection, Enter

   • [0] Actually, it's possible to trigger CodeLens via keyboard, but there are some limitations - see Easy pick codelenses with keyboard shortcut microsoft/vscode#91232
   • [1] Naive algorithm doesn't not produce that many CodeLenses

   We could display only one test function (per type) as a CodeLens (with title like Go to TestXxx (has X more tests)) and list all the test functions in the Source Actions menu. This approach should address all the mentioned issues.

[gabyhelp]

Related Issues

• x/tools/gopls: better "run this test" UX #67400
• x/tools/gopls: story for custom codelens providers #40516

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[IlyasYOY]

Hi! I think this is a fantastic idea and I’m really excited to see it land.

One suggestion I have is to avoid getting bogged down in finding a “perfect” algorithm for locating the corresponding tests right away. For an initial implementation it’s perfectly fine to rely on the existing naming conventions, especially for examples.

The Go blog defines the naming rules for Example functions here: https://go.dev/blog/examples#example-function-names

func ExampleFoo()        // documents the Foo function or type
func ExampleBar_Qux()    // documents the Qux method of type Bar
func Example()           // documents package as a whole

You can start by matching these patterns and, if possible, reuse any code that already handles them. Once the basic behavior is in place, the matching logic can be refined later.

Thanks for the great proposal – looking forward to seeing it in action!

[ShoshinNikita]

One suggestion I have is to avoid getting bogged down in finding a “perfect” algorithm

Yeah, I agree. The linked CL already implements the "naive algorithm" I described in the issue description

[gopherbot]

Change https://go.dev/cl/696395 mentions this issue: gopls/internal/golang: implement Go to TestXxx CodeLens and Code Action

[xieyuschen]

Hi @ShoshinNikita , the feature is cool and i'm looking forward it.

Go doesn't have a strong naming convention yet, as far as I know. So discussing the matching rule will take some time.

Official go vscode plugin has an action to generate unit test, see the docs here. You can consider to follow its convention at the beginning so regardless how users arrange their test cases, this feature always work for vscode generated test cases.

But I'm not sure the status of this unit test generation tool, and whether it's a desired convention in the long run. cc: @h9jiang

Besides, example has a strong naming convention, so why not consider to support it first as:

(1): the codelens feature support is the same regardless test or example
(2): no algorithm discussion

[ShoshinNikita]

So discussing the matching rule will take some time.

From my experience, most test functions follow these naming conventions:

• TestReplace for Replace or replace
• Test_replace for replace
• TestBuffer_Write for (Buffer).Write

Gopls' gopls.add_test action follows them as well. So, I don’t think there's much to discuss about matching rules.

My original concern was how to (or even should we) match TestDeletePanics with Delete and TestDeleteFunc with DeleteFunc (but not Delete). However, I think I've managed to improve the matching algorithm: it still follows the conventions, but can also handle the mentioned cases (the detailed description and implementation can be found at https://go.dev/cl/696395).

---

Right now, my main question is what to do with functions that have too many tests, like slices.Replace:

We can:

1. Show all test functions.
2. Show only one test function per type (Test, Benchmark, etc.), and display the full list in the "Source Action" menu:

IMO, the ideal solution would look something like this. But I believe this window is exclusive to VS Code (or even only to the official Microsoft extensions)?

[h9jiang]

There might be some similarity between the issue #74378 and this issue. The same part is how to locating the right test function based on the existing function name and the existing functions available from the test file.

As for the test naming, the gopls add test source code action follows the old gotests binary. I'm not very sure if this is the right naming convention but should be sufficient for most of use cases.

As for Code Lenses, I think we are normally kind of careful when introducing code lenses because they are highly visible in the IDE. There is only three as far as I know for the Go source code. There are several available in the go.mod file. A less visible form may be preferred @findleyr

As for the scrrenshot you provided for find references, @ShoshinNikita, the Peek References. If I understand this correctly, it is just a way of rendering references. It would be amazing if there are some way we can to a lsp find references with additional query parameter like: {file:*_test.go}. Then it will be able to render this for us.

The idea is also shared with another feature request "Write Reference", #74997 it would be great to query with parameter {kind: write}

At this moment, LSP 3.17 only allow us to send additional request field "includeDeclaration".