BufferRedirect is broken in unit tests

[soenkehahn]

This example from the readme fails when put into a unit test:

use std::io::Read;
use gag::BufferRedirect;

let mut buf = BufferRedirect::stdout().unwrap();
println!("Hello world!");

let mut output = String::new();
buf.read_to_string(&mut output).unwrap();

assert_eq!(&output[..], "Hello world!\n");

output is empty when assert_eq is executed.

rustc --version is rustc 1.33.0 (2aa4c46cf 2019-02-28).

[Stebalien]

What operating system? This works for me on Linux.

[soenkehahn]

Yeah, on linux.

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.10
DISTRIB_CODENAME=cosmic
DISTRIB_DESCRIPTION="Ubuntu 18.10"

After some experimenting I figured out that it works if put into a main function. It doesn't work when put into a unit test (with #[test]). My main use-case for gag is to capture stdout and stderr during tests, to write tests that ensure that some function writes something to those streams. I'll edit the issue description.

[Stebalien]

Ah. So, rust uses a super-special set_print function to override where println writes data when testing (but not in doc tests?). Unfortunately, there's not much I can do about that.

[Stebalien]

(at least I think that's what's happening here)

[Stebalien]

Actually... I'm not sure.

[assapir]

Any news regarding this? :(

[Stebalien]

Unfortunately, no. Any help debugging would be appreciated.

[assapir]

As far as I could figure out this is because by default, cargo test redirect the output so it won't show up. Running with -- --nocapture will actually solve the problem. Then the problem is that it run tests in parallel.

[soenkehahn]

You can run tests in sequence with --test-threads=1 for what it's worth.

Personally I don't like that rusts unit tests mess with stdout like that. It has a lot of downsides, besides breaking gag-rs... :/