go.test.file always passes if current file is not test file

[AlekSi]

If I invoke go.test.file when current file is not a test file, it says "Success: Tests passed.", but in fact, no tests were run.
go.test.cursor handles this situation, go.test.package works as expected.

[lukehoban]

Technically go test returns success in this case, which is why we say Success: Tests passed. It's not clear this is wrong either - especially since in these cases you also see a message that there were no tests.

?       github.com/GoogleCloudPlatform/golang-samples/docs/managed_vms/helloworld   [no test files]
Success: Tests passed.

What would you suggest doing here? PR's welcome.

[AlekSi]

go test can't be used with single non-test file. I'm talking about invoking go.test.file for package which has test files, but the current file is not a test. What I see in VSCode in this case:

PASS
ok      github.com/foo/bar  0.013s
Success: Tests passed.

But if fact no tests were run.
If the current file is a test file, it runs tests in this file.

I suggest to either run tests in foo_test.go if the current file is foo.go, or not run tests at all and explicitly say that no tests were run.

[davyzhang]

I think it's a very good idea to auto map current go file to its test file foo.go map to foo_test.go

go has its standard name convention here

[ramya-rao-a]

Inlcuding @ironcladlou here, as he had originally written the test related commands in the Go extension.

@ironcladlou Thoughts? I agree with @AlekSi and @davyzhang that we can map the test file as per naming conventions

[ironcladlou]

A bit of background: the current "test file" implementation works like this:

1. Collect all functions in the current file which look like test functions (regardless of the filename)
2. Execute go test in the package the current file lives in with a filter (via -run) on the identified function names

The reason it works this way is because go test against a specific file (not a package) doesn't execute in the context of the file's compiled package, and rarely does what a user would want in this situation.

Given the design of the function, which is to actively collect and execute tests, it seems reasonable to me that the command should not bother executing go test if no test functions were found in the current file.

It also seems reasonable to add an additional check in the test function scanning logic to return early if the current file doesn't appear to be a _test.go file since running go test against the package wouldn't find such a file anyway.

[ramya-rao-a]

The latest update (0.6.53) has the fix to this issue.
The fix being that if current file is not a test file, then an error message is shown if you attempt to run Go: Test File or Go: Test at cursor