-
Notifications
You must be signed in to change notification settings - Fork 18k
proposal: testing/test: Add {T,B}.RawLogf methods #14128
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
Comments
I don't think we want to grow the One option that might be less invasive is to introduce a magic t.Logf("some value = %v", val, testing.NoDecorate) Where NoDecorate is:
... so users can't replace it, supports ==, and fits nicely in an interface{} for |
One issue I see with your proposal @bradfitz is that @akalin-keybase does the assertion library dislike the decoration because the file/line would always be in the assertion library? |
@adg yeah. I've run into this myself, too, where I want to redirect some logger to use |
Considering what I wrote above, I think |
I still don't like it. I'd prefer something extensible that also lends itself towards resolving the report-file/line-N-stack-frames-up issue. (forget its number and on poor connection) We did make the testing.TB interface have a private method so people can't implement it without embedding a T or B, so we can extend it, but I'd rather not. |
Indeed, it'd be nice to solve #4899 in the process of this one, if we solve either. If we had |
Could the problem that prompted this proposal be solved by #2981? If so, I suggest closing this issue in favor of that one, which has been accepted. |
If I'm reading the proposal right, I don't think so. In particular, it looks like the entire log for a test is a single field in the
So I think that field would look like: |
Either solution proposed here so far would be wonderful. I'm the author of GoConvey, gunit, and assertions and have long been frustrated that there wasn't a nice way to squelch/tweak the decorations added by the testing package. |
The proposal in #2981 is coming along nicely (blocked on me) so I think we should decline this in favor of that one. |
@adg - I don't see how the work being done on #2981 resolves this particular issue. Don't get me wrong, I'm really excited to have a |
@adg the creator of this issue already explained in #14128 (comment) why #2981 doesn't solve this problem :\ This is about the testing framework controlling output in a way that can only be overridden with hacks and half-measures. This proposal is one specific idea for addressing this issue (which is more thoroughly discussed in #4899). |
Sorry, I skimmed that comment when I was revising this issue. But the proposal does cover this use case. Output and test logs are emitted as a stream JSON objects as the tests execute. That should be sufficient to implement any kind of UI layer on top of the JSON output. I'm happy to reopen this proposal if that's not the case. |
Yeah, it's all about being able to modify the output of |
We're having another proposal review meeting now. Nobody is excited about this. If people want to reform or recolor the output, they can post-process the output with a wrapper tool, especially with the JSON output. But we don't want everybody to start picking their subjectively favorite colors (literally) for the test output. Consistency is nice. Sorry, I'm going to close this. |
Currently,
{T,B}.Logf
calls intoc.log
, which callsdecorate
on the argument (which prefixes with the file/line, etc.) before appending it toc.output
. A library that wants to override this decoration has to resort to printing out\r
as a hack, e.g. https://github.com/stretchr/testify/blob/master/assert/assertions.go#L207 .What if
T
andB
exposed an additional methodRawLogf
, which wouldn't calldecorate
on the argument before appending it toc.output
? Then the above hack wouldn't be necessary.The text was updated successfully, but these errors were encountered: