Unable to test TTY behavior about assert_cmd

[snshn]

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.

[epage]

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]

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

[smoelius]

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

[snshn]

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...