Rust: libtest - capture stderr from tests

Created on 6 Mar 2017  Â·  10Comments  Â·  Source: rust-lang/rust

I'm currently having a problem with testing libraries that use log with either env_logger or flexi_logger in their tests. In the "real world", they should log to stderr, but libtest (and, by extension Cargo) doesn't capture stderr from tests, so I have to jump through hoops to get these libraries to log to stdout instead, or sift through huge logdumps.

Would it be possible to capture stderr from tests?

I originally posted this on the Cargo repo, but was told to file here. Possibly related to #31983, but I've tried limiting the test threads (RUST_TEST_THREADS=1) with no result.

A-libtest C-feature-request

Most helpful comment

I agree on this.

For a little more detail;

Consider the following

#[macro_use]
extern crate log;

fn do_stuff() -> bool {
    println!("println");
    error!("error");
    true
}

#[test]
fn my_test() {
    assert_eq!(true, do_stuff());
}

run: cargo test -- --nocapture

actual output:

running 1 test
println
test my_test ... ok

expected output:

running 1 test
println
error
test my_test ... ok

All 10 comments

I agree on this.

For a little more detail;

Consider the following

#[macro_use]
extern crate log;

fn do_stuff() -> bool {
    println!("println");
    error!("error");
    true
}

#[test]
fn my_test() {
    assert_eq!(true, do_stuff());
}

run: cargo test -- --nocapture

actual output:

running 1 test
println
test my_test ... ok

expected output:

running 1 test
println
error
test my_test ... ok

Using slog-envlogger (and other slog crates) one can easily have a logger that logs to stderr, stdout, file... whatever, with colors, in one of several format and if combine it with control of RUST_LOG variable. Just saying...

@dpc Not sure it would help, since it seems cargo test, even with the --nocapture swallows stderr. Only stdout is shown.

@ martinlindhe ... Edited my original coment. Slog doesn't care. Log to stdout, stderr, file. Or even open new raw 1 file descriptor and circumvent cargo test jail.

I actually should create slog-test crate specifically for that purpose... Ping me on slog gitter if you're interested. I guess it's enough of slog advertising. :D

@dpc, Okay.. so I can make a custom slog logger that outputs to stdout, thus allow cargo test to fetch the output. Gotcha.
Will also checkout slog when time permits!
But I think it would benefit the end user more if cargo test would display stderr, even if it is hidden behind a rather obscure flag as --nocapture.
Especially considering the log crate is the default logger as documented on rust-lang.org

Yes, I agree. Not everyone is in a position to use slog, as awesome as it
is.

On Fri, Mar 31, 2017, 15:36 Martin Lindhe notifications@github.com wrote:

@dpc https://github.com/dpc, Okay.. so I can make a custom slog logger
that outputs to stdout, thus allow cargo test to fetch the output. Gotcha.
But I think it would benefit the end user more if cargo test would display
stderr, even if it is hidden behind a rather obscure flag as --nocapture.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rust/issues/40298#issuecomment-290823247,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADI0_dspanD5UUkSfN3CQYGj7A2WUYXLks5rrWPbgaJpZM4MUXd0
.

Any updates on this?
Does this mean that right now using rust log I can't see them in tests?

AFAIU libtest now captures "stderr" and "stdout" but does so in a way that isn't compatible with some loggers that try to use the standard stderr/stdout without using something like println!(). For example https://github.com/sebasmagri/env_logger/issues/107 is discussing workarounds but it has drawbacks.

Another minor issue is that while libtest does capture println!() and eprintln!() output, they are both output on and labeled as "stdout" only.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Robbepop picture Robbepop  Â·  3Comments

SharplEr picture SharplEr  Â·  3Comments

dnsl48 picture dnsl48  Â·  3Comments

modsec picture modsec  Â·  3Comments

mcarton picture mcarton  Â·  3Comments