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
testing: Testable examples collapse Output
newlines, making them impossible to pass
#59191
Comments
Potential solutions
I'm guessing (1) has the least likelihood of breaking things for people, but it is still non-optimal - since it's not technically testing that output is correct (in some scenarios it's vitally important to be sure the output contains multiple newlines, so the test is effectively not a test.. whilst that clearly should be covered by unit tests - it's still odd to have a formalised test scenario which ignores the validity of output) |
2 should be the way forward. |
cc @bcmills |
The documented behavior is that “The comparison ignores leading and trailing space”, so collapsing interior newlines does seem incorrect. However, the To minimize the number of existing examples that break, I think this should probably be gated on a |
Change https://go.dev/cl/479119 mentions this issue: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?What did you do?
Output
annotation is modified by thetesting
parserMinimal example
Viewable here: https://go.dev/play/p/LFktKVr75lz
ExampleFoo
function returns data containing successive newlines:ExampleFoo
contains an embeddedOutput:
annotation with the same expected output:Output
andstdout
are compared, with leading and trailing whitespace removedWhat did you expect to see?
Output:
should be parsed as-is, not modified (beyond trimming leading and trailing whitespace)What did you see instead?
The multiple empty lines are collapsed into a single empty line
Additional context
Did a little hunting to see if I could find a root cause, no success yet
Currently suspect it's either hidden somewhere within the
testing
package, or is an unintended side effect of how chains of single line comments are parsed byast
The text was updated successfully, but these errors were encountered: