Thanks for the feature request. This makes sense to me, but is probably not going to be a high priority for the team right now (will discuss with others in our weekly triage meeting).

Added 'help wanted' as I think this would be relatively straightforward to contribute.

@findleyr Can I have a go at it? Though I would need some guidance to get started.

Sure, though I think @hyangah or @firelizzard18 might be better able to advise on how to get started.

As I see it, today the main advantage of adding this command over running the equivalent on the command line is integration with go.testEnvVars, go.testFlags, etc, as @pckhoi pointed out #1602 (comment). Down the road, it may be possible to integrate such a command with the testing API, so that test items in the test explorer are updated.

@n1lesh The main problem will be deciding the current directory and/or packages to test. In a single workspace environment, you could set the CWD to the workspace root and test all packages (./...), but that could be problematic if the same function name is used in multiple packages. And it wouldn't work for multi-root workspaces. You could derive the CWD from the active editor, but if that's how you do it, the command should be "Go: Test current package with custom -run" or something like that. You could expose the command only as a context menu option on folders in the explorer (right click, "Go: Test -run"), but that limits its utility. You could open a quick pick or something, but I'm not sure how to make that work well for large projects.

For the actual implementation, I would change the type of the functions property of TestConfig to string[] | string and then update the function that builds the -run flag arguments: if testconfig.functions is a string, return ['-run', testconfig.functions]. Then, the command implementation (in src/goTest.ts probably) can be:

const goConfig = getGoConfig(packageDirUri);
const isMod = await isModSupported(packageDirUri);

const testConfig: TestConfig = {
	goConfig,
	dir: packageDirUri.fsPath,
	flags: getTestFlags(goConfig, args),
	functions: userSuppliedRunFlagArgument,
	isMod,
};
// Remember this config as the last executed test.
lastTestConfig = testConfig;
return goTest(testConfig);

EDIT: I fixed the link to TestConfig.functions.

@firelizzard18 I guess it's better to implement it at the current active package level for the reasons you mentioned.

Just one question, to run the custom -run flag at the package level, wouldn't path.dirname(editor.document.fileName) give the current active package path, as the same is used by testCurrentPackage as well? Is there any significance of packageDirUri which I am not understanding?

@n1lesh I meant packageDirUri as a placeholder for whatever logic you use to decide on a directory. path.dirname(vscode.window.activeTextEditor.document.fileName) will be the path of the directory of the currently active editor, which is what the run package tests codelens and Go: Test Package command do.

@firelizzard18 Got it and thanks for all your suggestions and feedback.

Change https://golang.org/cl/347209 mentions this issue: src/goTest: Add command Test Current Package With Custom Run

I have tested the patch in 347209 and while it may do what it says, I find it very limited.

A frequent thing for me is to rerun a test (or test case) until I have fixed it. The above command allows me to run a specific test case, but I constantly need to paste in the -run pattern on every iteration, which is not something that I'm prepared to do.

@bep I wouldn't know if we can keep the initial command cached for the user to re-use it, if that's what you're looking for. @firelizzard18 Would you be able to suggest something on this?

@n1lesh yes, something like that ... I tested that and that works kind of naturally ... until you switch to another package. But I guess that's an OK compromise.

"Go: Test Previous" (and also Debug Previous) is the command for the purpose and it seems the current CL does it already.
A question that hold me back on this change is though what prevents users from configuring their own tasks.json as they want.