Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: testing: allow tests to fake the position information reported by testing.T.Error #18848
I often write tests for language tools and such tests typically contain a small amount of Go code and a larger amount of data consisting of source code in the target language. When those tests fail, they always report the same (uninteresting) position in the Go program, followed by the error message containing the (very interesting) position within the target file.
Since I usually step through error messages in an editor, it would be nice to suppress the Go positions and show only the data file positions. Can we add a feature that allows a call to testing.T.Error to report a different file/line that that of the call to Error itself? I appreciate the concern that misuse of this feature could make it hard to find the actual line of Go code that failed, but I would be happy to accept that risk.
referenced this issue
Jan 30, 2017
Me not. And not hard, but virtually impossible in some cases.
That's IMO the correct approach.
I wonder if it's better to provide some API to override the file:line, or whether it would be better to provide a way to suppress the built-in file:line printing. I'd probably lean towards the latter.
Something like that was requested in the now-closed #14128, but maybe it could be revisited with better motivation.
changed the title
testing: allow tests to fake the position information reported by testing.T.Error
Mar 6, 2017
Note that you can put newlines in the messages too, so that you could get a message (by putting the file:line in yourself) like:
I don't know if your editor can jump to the indented file.txt:4, but it seems like it should be able to.
Yes but if I'm the one debugging your test later, I may not want to accept that risk. Or maybe you six months from now will regret taking that risk. I think I'd be very upset to get a Go test failure that didn't tell me at least some line of Go code that I could start with. It seems good enough for editor jumping to print an additional file:line pointer, instead of replacing the code pointer with a data pointer.
More generally, I get very worried when I hear features defended with "I would be happy to accept that risk". We typically don't ask users to accept risks. That kind of argument for "risky power-user features" reminds me of other languages, not Go.