proposal: testing: allow tests to fake the position information reported by testing.T.Error

[alandonovan]

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.

[bradfitz]

Dup of ongoing #4899?

[alandonovan]

Not exactly the same idea, but I've updated that thread to briefly describe this idea. Thanks.

[josharian]

Seems pretty orthogonal to #4899, at least in terms of required API additions.

[cznic]

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.

Me not. And not hard, but virtually impossible in some cases.

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.

That's IMO the correct approach.

[cespare]

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.

[rsc]

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:

foo.go:123: something is wrong
    file.txt:4: this line

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]

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.

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]

Based on the goal that every failure print at least the location of some source line, declining.