Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testing: optionally include full (or relative) path name #37708

stapelberg opened this issue Mar 6, 2020 · 3 comments

testing: optionally include full (or relative) path name #37708

stapelberg opened this issue Mar 6, 2020 · 3 comments


Copy link

@stapelberg stapelberg commented Mar 6, 2020

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.

Copy link

@mvdan mvdan commented Mar 6, 2020

@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 toothrot added the NeedsInvestigation label Mar 9, 2020
@toothrot toothrot added this to the Backlog milestone Mar 9, 2020
Copy link

@toothrot toothrot commented Mar 9, 2020

also ccing @mpvl

Copy link

@aryman-glympse aryman-glympse commented Jun 11, 2021

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)



Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants