testing: optionally include full (or relative) path name

[stapelberg]

Previous discussion happened in issue #21119.

Currently, t.Error calls print only the base name of the source file.

This is fine when running a single test, but in larger projects, it is a significant productivity boost to have relative (or full) path names, which make the “jump to next compilation error” feature in popular editors work.

I understand the outcome of #21119 (can’t change the default), but I suggest adding a knob to opt into printing relative or full paths.

Perhaps this could be similar to log.SetFlags, where you can specify Llongfile or Lshortfile?

Let me know if this would be okay, and I’d be happy to send a CL.

[mvdan]

@rogpeppe, @myitcv and myself discussed a very similar idea not too long ago.

It's unfortunate that we can't change the default. However, there is some precedent for such an opt-in flag:

$ go tool compile -h 2>&1 | grep -- -L
  -L	show full file names in error messages

I also wonder if go test could transform filename paths transparently, when it buffers output from test binaries. The only case where the test binary output goes straight to the terminal is when go test is run without arguments - and, in that case, the paths are already relative to the current directory, as we're testing the package in the current directory too. Transforming paths should be possible to do, given that test2json does very similar parsing of plaintext test output.

[toothrot]

also ccing @mpvl

[aryman-glympse]

Is there anyway we can do this similar to how the log package sets flags for log outputs?

// setting longfile in package log.
log.SetFlags(log.Lmicroseconds | log.Llongfile)

Proposed:

testing.SetFlags(testing.Llongfile)

[dnephin]

#55976 was closed as a duplicate of this issue, but this one seems to be stuck in the backlog. Can we turn this into a proposal?

Moving my comment here for consideration:

I've noticed occasionally GoLand links to the wrong file when tests are run from the terminal window inside GoLand. I suspect it's for exactly the reason described above. The filename is ambiguous. There can be multiple files with the same name in a project, and when tests are run from the terminal window, it doesn't know which of those files to link to. An absolute path would allow this feature to work reliably.

This problem exists even when t.Helper is used correctly. The tooling that is reading the output doesn't necessarily know which directory is the current working directory because tests can be run from any directory.

I suspect the absolute path is really only useful when the output is being read by another application, and the filename is better when the output is being read by a human. Instead of a new flag to enable this behaviour, the existing -json flag on go test could be used to enable output of absolute paths instead of filenames.

1c72ee7 recently added -test.v=json, which I think allows testing to detect if -json is set or not.