Repository navigation
proposal: testing: allow tests to fake the position information reported by testing.T.Error #18848
Description
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.
Activity
bradfitz commentedon Jan 30, 2017
Dup of ongoing #4899?
alandonovan commentedon Jan 30, 2017
Not exactly the same idea, but I've updated that thread to briefly describe this idea. Thanks.
josharian commentedon Jan 30, 2017
Seems pretty orthogonal to #4899, at least in terms of required API additions.
cznic commentedon Jan 30, 2017
Me not. And not hard, but virtually impossible in some cases.
That's IMO the correct approach.
cespare commentedon Jan 30, 2017
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.
[-]testing: allow tests to fake the position information reported by testing.T.Error[/-][+]proposal: testing: allow tests to fake the position information reported by testing.T.Error[/+]rsc commentedon 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.
rsc commentedon Mar 7, 2017
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.
rsc commentedon Mar 13, 2017
Based on the goal that every failure print at least the location of some source line, declining.