davepacheco / term-test

testing "term" crate behavior in unit tests

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

term-test

Tests the behavior of term’s `stdout() terminal.

Take a look at src/main.rs. The interesting bit is:

let t = term::stdout();
if let Some(mut term) = t {
    eprintln!("println to stderr (stdout found)");
    println!("println to stdout (before)");
    term.fg(term::color::GREEN).unwrap();
    write!(term, "terminal write to stdout\n").unwrap();
    term.reset().unwrap();
    term.flush().unwrap();
    println!("println to stdout (after)");
} else {
    eprintln!("println to stderr (stdout not found)");
}

Running this as a binary

If we run it as a program, we get what you might expect:

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/term-test`
println to stderr (stdout found)
println to stdout (before)
terminal write to stdout
println to stdout (after)
$

If you redirect stdout or stderr, you’re left with whatever you didn’t redirect in your terminal (as you’d expect):

$ cargo run > /dev/null
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/term-test`
println to stderr (stdout found)
$ cargo run 2> /dev/null
println to stdout (before)
terminal write to stdout
println to stdout (after)
$

You can redirect stdout to a file, and we’ll see that the output we wrote to the "terminal" is there, escape sequences and all:

$ cargo run > foo
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/term-test`
println to stderr (stdout found)
$ xxd foo
00000000: 7072 696e 746c 6e20 746f 2073 7464 6f75  println to stdou
00000010: 7420 2862 6566 6f72 6529 0a1b 5b33 326d  t (before)..[32m
00000020: 7465 726d 696e 616c 2077 7269 7465 2074  terminal write t
00000030: 6f20 7374 646f 7574 0a1b 2842 1b5b 6d70  o stdout..(B.[mp
00000040: 7269 6e74 6c6e 2074 6f20 7374 646f 7574  rintln to stdout
00000050: 2028 6166 7465 7229 0a                    (after).
$

Okay, so term gives you back a terminal interface for stdout regardless of whether it’s a real terminal.

Running this as a unit test

If we use --nocapture, we get all of the output, as you’d expect:

$ cargo test -- --nocapture
    Finished test [unoptimized + debuginfo] target(s) in 0.01s
     Running unittests (target/debug/deps/term_test-f7fd9a9422a0407e)

running 1 test
println to stderr (stdout found)
println to stdout (before)
terminal write to stdout
println to stdout (after)
test test_doit ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

$

and the individual pieces go where you (might) expect:

$ cargo test -- --nocapture > /dev/null
    Finished test [unoptimized + debuginfo] target(s) in 0.01s
     Running unittests (target/debug/deps/term_test-f7fd9a9422a0407e)
println to stderr (stdout found)
$ cargo test -- --nocapture 2> /dev/null

running 1 test
println to stdout (before)
terminal write to stdout
println to stdout (after)
test test_doit ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

What’s weird: if you don’t use --nocapture, you still get the terminal output! Even though you don’t usually get stdout from tests without --nocapture, and you don’t get the rest of the stdout:

$ cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.01s
     Running unittests (target/debug/deps/term_test-f7fd9a9422a0407e)

running 1 test
terminal write to stdout
test test_doit ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

$

How does that happen?

About

testing "term" crate behavior in unit tests


Languages

Language:Rust 100.0%