test utilities: easy way to simulate terminal context

[cre4ture]

addresses #5785
and addresses #1857
replaces if accepted PR #5858

let me know what you think. It's very easy to use. Just do a .simulate_terminal(true) and thats it.
I implemented in such a way that also stdin piping still works and also the capturing of stdout and stderr works as usual.
EDIT: For cases where the terminal size matters, there is no an additional function available:

.terminal_size(libc::winsize {
                ws_col: 40,
                ws_row: 10,
                ws_xpixel: 40 * 8,
                ws_ypixel: 10 * 10,
            })

Example:

#[test]
fn test_simulation_of_terminal_true() {
    let scene = TestScenario::new(util_name!());

    let out = scene
        .ucmd()
        .arg("sh")
        .arg("is_atty.sh")
        .terminal_simulation(true)
        .succeeds();
    assert_eq!(
        String::from_utf8_lossy(out.stdout()),
        "stdin is atty\r\nstdout is atty\r\nstderr is atty\r\n"
    );
    assert_eq!(
        String::from_utf8_lossy(out.stderr()),
        "This is an error message.\r\n"
    );
}

where is_atty.sh looks like this:

#!/bin/bash

if [ -t 0 ] ; then
    echo "stdin is atty"
else
    echo "stdin is not atty"
fi

if [ -t 1 ] ; then
    echo "stdout is atty"
else
    echo "stdout is not atty"
fi

if [ -t 2 ] ; then
    echo "stderr is atty"
else
    echo "stderr is not atty"
fi

echo "This is an error message." > /dev/stderr

true

[RenjiSann]

Is it ready to merge already, or are we waiting for further improvements ?

[cre4ture]

What is missing is a review and approval from one of the maintainers.
@sylvestre - I also did the squash commit now. Let me know what you think.

[tertsdiepraam]

I like it a lot! Excellent work! I only have some small questions.

I also think that we might want to be able to configure the terminal with this interface, but for now, the API is flexible enough I think. It's also about time we extract the test framework to a crate, so we can generate documentation for it. It's getting quite complex. That's something for another PR though.

I would like to wait for approval of one of the other maintainers before merging though.

One final question: have you seen any intermittently failing tests with this? Can we assume that this implementation is robust enough not to make our test suite fail unexpectedly (even more so then it already does 😅)

[tertsdiepraam]

Are these meaningful tests of env? If not, it could still be useful to have them (we're going very meta with tests for our test framework 😄), but maybe somewhere else?

[cre4ture]

ah, yes. This is a valid point. I used env here as a tool rather than to test itself. This is something I should cleanup. Do you have a proposal for a better location of these tests?

[tertsdiepraam]

Maybe in the file where the test framework is defined? It's an interesting question, we don't really have tests for the tests yet 😄

[cre4ture]

done

[cre4ture]

One final question: have you seen any intermittently failing tests with this? Can we assume that this implementation is robust enough not to make our test suite fail unexpectedly (even more so then it already does 😅)

I think its stable.

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)

[sylvestre]

thanks