Allow "subtest at cursor" to work with table-driven test setup

[schandra157]

Related issues

Issue	Work to be done
#2445	Statically detect simple table-driven tests
This issue	Support "run at cursor" for entries in a table
#1734	Let the user manually enter a test or subtest name to execute

---

Is your feature request related to a problem? Please describe.

In the case of Table driven Test model in GO programming, Currently, it's possible to run/debug test at the Function level. It would be great if its possible to be executed at the individual test level

Describe the solution you'd like
Have an option to Run and Debug at each individual Test level, which would be great to debug the individual test in case of issue and would be very handy feature

Additional context

The below Screen shot describes the problem

[findleyr]

Hi, this feature is available:
https://github.com/golang/vscode-go/blob/master/docs/commands.md#go-subtest-at-cursor

Does that meet your needs?

[suzmue]

Unfortunately, "Go: subtest at cursor" is pretty limited at the moment and does not work with table driven tests. Where would you expect the code lens to appear? In the definition of tests? On t.Run (with some way to specify which subtest)?

It would be reasonable for Go: subtest at cursor to request a subtest name via an input box if it cannot find a simple test name.

Issue #1579 is tracking updates to testing support for this extension, which may add some support for easier subtest running.

[schandra157]

Hi, this feature is available:
https://github.com/golang/vscode-go/blob/master/docs/commands.md#go-subtest-at-cursor

Does that meet your needs?

Yes, it will be helping us a lot.

[schandra157]

Unfortunately, "Go: subtest at cursor" is pretty limited at the moment and does not work with table driven tests. Where would you expect the code lens to appear? In the definition of tests? On t.Run (with some way to specify which subtest)?

It would be reasonable for Go: subtest at cursor to request a subtest name via an input box if it cannot find a simple test name.

Issue #1579 is tracking updates to testing support for this extension, which may add some support for easier subtest running.

Glad to see some Ideas around this, My opinion is to have code lens appear at definition of the test

[findleyr]

We couldn't do this in generality (for example if the test cases were outside the function scope), but it wouldn't be hard for gopls to provide code lenses for the common patterns of a slice of test cases in the function scope, or ranging over a literal.

We could add this feature as part of our migration to use gopls for generating test code lens.

[schandra157]

okay

[hyangah]

I guess users will still want to enter or select the subtest name after clicking a codelens. Currently, I don't think LSP's codelens+command allows that level of UX control yet. So the extension will need a middleware hack or the actual codelens implementation (based on info from gopls) if we want to implement it soon.