Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to test TTY behavior #138

Open
snshn opened this issue Nov 1, 2021 · 5 comments
Open

Unable to test TTY behavior #138

snshn opened this issue Nov 1, 2021 · 5 comments
Labels
enhancement Improve the expected question Uncertainty is involved

Comments

@snshn
Copy link

snshn commented Nov 1, 2021

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!

@smoelius
Copy link
Contributor

smoelius commented Nov 1, 2021

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

@snshn
Copy link
Author

snshn commented Nov 1, 2021

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
Copy link
Contributor

epage commented Nov 1, 2021

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 epage added enhancement Improve the expected question Uncertainty is involved labels Nov 1, 2021
@snshn
Copy link
Author

snshn commented Nov 2, 2021

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

@epage
Copy link
Contributor

epage commented Nov 2, 2021

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

yuja added a commit to martinvonz/jj that referenced this issue Jun 10, 2022
According to the NO_COLOR FAQ, "user-level configuration files [...] should
override $NO_COLOR." https://no-color.org/

Unfortunately this makes it harder to test the $NO_COLOR behavior since the
test environment isn't attached to a tty. We could allocate a pty or
LD_PRELOAD shim to intercept isatty(), but I feel it would be too much to do.

assert-rs/assert_cmd#138
@epage epage mentioned this issue Dec 14, 2022
mulkieran added a commit to mulkieran/stratisd that referenced this issue Apr 27, 2023
Substitute prompt_password for removed prompt_password.
Note that prompt_password prints the prompt string to /dev/tty, while
prompt_password_stdout printed the prompt to stdout.

Remove test that prints password prompt. Since the prompt goes to tty
rather than stdout, the test framework is not able to handle it. This is
a know limitation of the framework, see:
assert-rs/assert_cmd#138

Signed-off-by: mulhern <amulhern@redhat.com>
mulkieran added a commit to mulkieran/stratisd that referenced this issue May 1, 2023
Substitute prompt_password for removed prompt_password.
Note that prompt_password prints the prompt string to /dev/tty, while
prompt_password_stdout printed the prompt to stdout.

Remove test that prints password prompt. Since the prompt goes to tty
rather than stdout, the test framework is not able to handle it. This is
a know limitation of the framework, see:
assert-rs/assert_cmd#138

Signed-off-by: mulhern <amulhern@redhat.com>
mulkieran added a commit to mulkieran/stratisd that referenced this issue May 16, 2023
Substitute prompt_password for removed prompt_password.
Note that prompt_password prints the prompt string to /dev/tty, while
prompt_password_stdout printed the prompt to stdout.

Remove test that prints password prompt. Since the prompt goes to tty
rather than stdout, the test framework is not able to handle it. This is
a know limitation of the framework, see:
assert-rs/assert_cmd#138

Signed-off-by: mulhern <amulhern@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve the expected question Uncertainty is involved
Projects
None yet
Development

No branches or pull requests

3 participants