testing examples printing to stdout not working for global var

[psi....@gmail.com]

this caught me out, is it a bug?

https://go.dev/play/p/atJb8dZHoqi

[peterGo]

It looks like you have a bug in your code.

"In tests, standard output is accumulated during execution and dumped to standard output when done."

"Example functions may include a concluding line comment that begins with "Output:" and is compared with the standard output of the function when the tests are run."

In ExampleMain(), you improperly used the os.Stdout variable value as of the testing package initialization.

In ExampleMain2(), you properly used the os.Stdout variable value as of when the function was run.

testing package  
https://pkg.go.dev/testing@latest

Peter

[psi....@gmail.com]

#1 the two functions need to behave identically according to the syntax of the language.

#2 this is how working code operates, so testing needs to be able to handle it.

at a guess; 'testing' would appear to have some non-compliant reflection going on, in this edge-case.

but anyway; your reply has no relevance i can decern, and replying like this can put off useful comments. please don't get huffy i don't have the time/interest, just don't comment anymore.

[peterGo]

Please follow the Go Community Code of Conduct while posting here.  
https://go.dev/conduct

[Sean Liao]

Code needs to be written to be testable.

Peter is correct, you've taken a reference to an uninstrumented os.Stdout.

What you've written isn't identical wrt to the evaluation of stdout, so can't be expected to perform identically.

[burak serdar]

On Mon, May 2, 2022 at 9:00 AM psi....@gmail.com <psi....@gmail.com> wrote:

#1 the two functions need to behave identically according to the syntax of the language.

#2 this is how working code operates, so testing needs to be able to handle it.

at a guess; 'testing' would appear to have some non-compliant reflection going on, in this edge-case.

This is not related to reflection, but an edge case with the testing framework. Testing sets os.Stdout to something else before it starts running so that it can accumulate the output. For #1, you save the stdout before testing framework reassigns it, so it is printed to the output, and testing framework cannot see it. For #2, you are using the reassigned stdout, so testing can catch what you wrote to it.

 

but anyway; your reply has no relevance i can decern, and replying like this can put off useful comments. please don't get huffy i don't have the time/interest, just don't comment anymore.

On Monday, 2 May 2022 at 03:32:46 UTC+1 peterGo wrote:

It looks like you have a bug in your code.

"In tests, standard output is accumulated during execution and dumped to standard output when done."

"Example functions may include a concluding line comment that begins with "Output:" and is compared with the standard output of the function when the tests are run."

In ExampleMain(), you improperly used the os.Stdout variable value as of the testing package initialization.

In ExampleMain2(), you properly used the os.Stdout variable value as of when the function was run.

testing package  
https://pkg.go.dev/testing@latest

Peter

On Sunday, May 1, 2022 at 8:03:29 PM UTC-4 psi....@gmail.com wrote:

this caught me out, is it a bug?

https://go.dev/play/p/atJb8dZHoqi

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d8654a21-e060-4bee-842f-e6eb41d21878n%40googlegroups.com.

[simon place]

i see, thanks

the implementation of 'go test' (which the playground runs auto-magically.) replaces os.Stdout with a new reference behind the scenes before running the func, but after making global vars, so the code as written isn't strictly 'go' anymore.

https://go.dev/play/p/3FBjOmzYIiz?v=goprev

shame it couldn't have been done at a lower level, say mangling the OS pointer and preserving the go pointer.

i guess a comment explaining what is up with the surprising code i'm going to have to add, is the best i can do.

[burak serdar]

On Mon, May 2, 2022 at 2:57 PM 'simon place' via golang-nuts <golan...@googlegroups.com> wrote:

i see, thanks

the implementation of 'go test' (which the playground runs auto-magically.) replaces os.Stdout with a new reference behind the scenes before running the func, but after making global vars, so the code as written isn't strictly 'go' anymore.

The assertion that "the code as written isn't strictly go" is not correct. You just hit an edge case in the testing framework. Most testing frameworks that control the environment for the code under test will have edge cases. 

Use of globals almost always complicates things wrt testing. 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/994e20cc-c1c5-4e8c-a022-16a2e83a85a4n%40googlegroups.com.

[simon place]

actually just changing Example's to Test's with a string comparison seems to have the least friction.