Links to source files in go test output are not correct for when testing all pkgs in workspace

[doxxx]

Sample project: gotestbug.zip

Steps to Reproduce:

1. Load the sample project in VS Code
2. Invoke the Go Test All Packages in Workspace action.
3. go test output looks like the following:

Running tool: C:\Go\bin\go.exe test -short -timeout 30s ./...

--- FAIL: TestDoStuff (0.00s)
	c:\Users\gordon.tyler\go\src\gotestbug\stuff_test.go:10: oh noes!
FAIL
FAIL	gotestbug/stuff	0.060s
Error: Tests failed.

The link to the source file is incorrect. It should be c:\Users\gordon.tyler\go\src\gotestbug\stuff\stuff_test.go.

[doxxx]

However, if I open up stuff_test.go and invoke the Go: Test Package action, the go test output contains the correct source file link:

Running tool: C:\Go\bin\go.exe test -short -coverprofile=C:\Users\GORDON~1.TYL\AppData\Local\Temp\go-code-cover -timeout 30s gotestbug\stuff

--- FAIL: TestDoStuff (0.00s)
	c:\Users\gordon.tyler\go\src\gotestbug\stuff\stuff_test.go:10: oh noes!
FAIL
coverage: 100.0% of statements
FAIL	gotestbug/stuff	0.067s
Error: Tests failed.

[ramya-rao-a]

When running Go Test All Packages in Workspace, we run go test ./... with the workspace root as current working directory. The path of the file of the failing test in the output of go test ./... is relative to the package path which isnt the current working directory.

I dont see a good fix here other than to skip trying to complete the relative paths when testing the entire workspace.

Thoughts?

PRs are welcome.
The place to make the fix is: https://github.com/Microsoft/vscode-go/blob/0.6.78/src/testUtils.ts#L118

[doxxx]

The FAIL line following the error has a package path which could be used to resolve the file correctly. But that would mean a more complicated parsing setup since you can’t just recognize file paths on a per line basis.

[doxxx]

I’ll take a look at the code. 👍

[doxxx]

It looks like go test itself buffers all the failures for a package and outputs them in one chunk per package, so doing a similar kind of buffering in the goTest function won't hurt. That should allow us to buffer output until a package FAIL line is encountered and then step back through the buffered output to alter the file paths and then emit the whole block to the output channel.

[doxxx]

Do you have any particularly strong feeling about emitting fully-qualified paths? I notice that relative paths in the go build output in a terminal are automatically linked by VSCode. I find relative paths easier to read.

[ramya-rao-a]

In the terminal the relative paths do get linked, I am not so sure about the output channel though

[doxxx]

Alas, relative paths are not linked in the output channel.

[ramya-rao-a]

This bug fix is now out in the latest update to the Go extension (0.6.80)