assert_cmd icon indicating copy to clipboard operation
assert_cmd copied to clipboard

Unable to test TTY behavior

Open snshn opened this issue 4 years ago • 5 comments

Using crate atty:

let stdout_is_a_tty: bool = atty::is(Stream::Stdout);
if stdout_is_a_tty { "<encode data into lossy UTF-8 to print into the terminal>" } else { "<binary output>" }

When I run tests, stdout_is_a_tty is always false, hence I can't test the textual "to-terminal" output of my program, which I really need to test somehow. Ideally there should be some switch in assert_cmd... I really don't want to use env variables to force that behavior, it'd be very hacky.

Thank you for creating and maintaining this crate, really helps me test my software even the way it is right now!

snshn avatar Nov 01 '21 01:11 snshn

Just a thought: maybe --nocapture would make a difference(?).

smoelius avatar Nov 01 '21 01:11 smoelius

Just tried it, seems to be leading to the same behavior as without it, just slightly different verbose output. I think there needs to be a switch somewhere that toggles on "this should run exactly as when the user runs it in their terminal". The current default behavior is correct, since in theory, tests do run not directly in the terminal, but in their own environment (cargo, in this case). I just need to test things and let cargo know to make the program think it's inside of a TTY when it comes to STDOUT.

snshn avatar Nov 01 '21 02:11 snshn

We always capture stdout/stderr so we can run assertions on them. We'd need to add support for something like portable_ptr to do this.

Overall, I'd recommend providing a flag / env variable to give users control over this behavior. At that point, its only a question of whether the auto-detection works or not.

epage avatar Nov 01 '21 13:11 epage

You're probably right on the money about the software being tested that must be responsible for being able to behave a certain way, not the testing framework. I will look at wget, curl, and other popular tools to see what format they use for ENV variables (naming is important for things like that sometimes, wouldn't want to make it too weird). Meanwhile, could you please hint at how to provide ENV variables to my CLI tool via assert_cmd, is it just .arg() put before the tool's name, or it has kind of cross-platform wrapper for it, or it should be put in front of cargo test? Thank you...

snshn avatar Nov 02 '21 00:11 snshn

Check out https://doc.rust-lang.org/std/process/struct.Command.html#method.env

epage avatar Nov 02 '21 01:11 epage