You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 1, 2024. It is now read-only.
But for this breaks the capture-output functionality of Ward. Is there a standard way of asserting the stdout + stderr in tests and not breaking anything?
The text was updated successfully, but these errors were encountered:
This is a bit of a tricky area. At the point where the fixture executes, hasn't sys.stdout already been replaced with something else by Ward? If you print it out you might see that it has.
An idea that might work is this:
Inside your fixture, you could re-assign sys.stdout to some proxy file-like object which captures the output and then forwards it on to whatever was in sys.stdout before. Something like sys.stdout = CapturingProxy(sys.stdout).
CapturingProxy would be a file-like object implementing read/write etc, and storing everything that it proxies through to the original stdout. Then, you'd return the content that the CapturingProxy holds.
The scope of the fixture would probably need to be Test as well for this to work, so that each test only records what was written during its own execution.
FWIW here's a hacky setup I'm using. Instead of calling the functions directly in the tests, I wrap them with a utility function that temporarily sets stdout to a StringIO, and returns the output as str.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I've tried to set up my own fixture for capturing the output:
But for this breaks the capture-output functionality of Ward. Is there a standard way of asserting the stdout + stderr in tests and not breaking anything?
The text was updated successfully, but these errors were encountered: