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

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

Closed
alandonovan opened this issue Jan 30, 2017 · 8 comments

Comments

Projects
None yet
7 participants
@alandonovan
Copy link
Contributor

commented Jan 30, 2017

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

This comment has been minimized.

Copy link
Member

commented Jan 30, 2017

Dup of ongoing #4899?

@alandonovan

This comment has been minimized.

Copy link
Contributor Author

commented Jan 30, 2017

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

@josharian

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2017

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

@cznic

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2017

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

This comment has been minimized.

Copy link
Contributor

commented 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.

@rsc rsc changed the title 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 Mar 6, 2017

@rsc rsc added this to the Proposal milestone Mar 6, 2017

@rsc

This comment has been minimized.

Copy link
Contributor

commented 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:

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

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2017

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

@rsc rsc closed this Mar 13, 2017

@golang golang locked and limited conversation to collaborators Mar 13, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.