Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

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

Closed
AlekSi opened this issue Apr 19, 2016 · 6 comments
Closed

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

AlekSi opened this issue Apr 19, 2016 · 6 comments

Comments

@AlekSi
Copy link
Contributor

AlekSi commented Apr 19, 2016

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
Copy link
Contributor

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
Copy link
Contributor Author

AlekSi commented Apr 21, 2016

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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

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.

samherrmann pushed a commit to samherrmann/vscode-go that referenced this issue Jan 13, 2017
mattetti added a commit to mattetti/vscode-go that referenced this issue Jan 16, 2017
…ild-i

* 'master' of github.com:Microsoft/vscode-go:
  Moved debugging doc to a separate wiki
  Make a copy of process.env when setting VSCODE_GOTOOLS
  Debugger cannot read settings
  Improve error handling of test coverage (microsoft#721)
  Use proper plurality in output (microsoft#720)
  Fixes microsoft#303 Dont run test if current file is  not test file
  Added a note on how to debug single tests
  Allow Go tools to be installed in a separate GOPATH (microsoft#351)
  Fix typo in README.md (microsoft#715)
  Honor the 'cwd' launch configuration argument (microsoft#714)
@ramya-rao-a
Copy link
Contributor

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

@vscodebot vscodebot bot locked and limited conversation to collaborators Jan 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants