Allow to display stdout, while silencing test harness.

[ivan-aksamentov]

One of the things I am struggling with in Rust is the noisy default test harness.

Nextest hides stdout, and prints pretty short messages instead, making it a much more pleasant experience. Thank you for making it happen!

However, I sometimes need to print!() or to dbg!() something in the program while debugging and this requires either adding --nocapture or --success-output=immediate, which then does display my printouts, but also unleashes the havoc of the default test harness again, because Nextest cannot tell apart the user's stdout and the test harness stdout:

I can of course use the filters, to only run the tests where I print something. This reduces the amount of printed noise. But then I may forget to run all other tests while making code changes. This is additional movements and mental load to remember all the different configs and to switch between them. When repeated daily this is exhausting.

Ideally, I'd like to be able to silence the default test harness while allowing for user's stdout to be displayed at all times. I believe this should not need to be configured and this is the default behavior in all test frameworks in all languages I've ever seen.

Do you think Nextest can help me with that?

Any other ideas of how this can be achieved?

Related:

• Cannot silence test runner rust-lang/rust#38758
• Is it possible to display intentionally leaked output from tests? #930
• https://rust-lang.github.io/rfcs/2318-custom-test-frameworks.html

Thanks again for the fantastic tool! It already improves my daily work a lot!

[sunshowers]

Thanks. Do you mean removing the lines that say:

"running 1 test"
"test [...] ok"
"test result: ok. [...]"

Interesting thought for sure! I think we can probably do something of that kind, yeah.

[ivan-aksamentov]

@sunshowers Yes, these lines. My understanding is that it will make stdout mostly empty and that most --- STDOUT lines will also go away, except for cases where I print things explicitly.

P.S. Nextest is so good I thought it should probably become a part of the default test harness. Or perhaps become one of the custom test frameworks once that feature is stabilized. My understanding is that custom test frameworks would allow to write a custom main function(s) as well as have an API to enumerate test modules and cases - it will probably simplify the architecture of Nextest and will remove the unwanted stdout entirely.