Tests should output the name before running

[viraptor]

Currently with standard testing, unittests only print out the name + result after they finish. This is usually good, apart from when tests hang. In that case you have to manually try to find the right test, which can take some time depending on a project.

Test build should either output the test name before running it by default, or at least print out a new message about starting the test run when some option is provided.

Of course this gets harder when multithreded testing is active.

[apasel422]

CC #2873.

[huonw]

The only reason this doesn't happen is multithreaded testing is enabled by default: if it is disabled (e.g. setting the env var RUST_TEST_THREADS=1) the test runner does print the test name when it starts running it. E.g.

// slowtest.rs
use std::thread;

#[test]
fn foo() {
    thread::sleep_ms(1000);
}

#[test]
fn bar() {
    thread::sleep_ms(500);
}

Compile that with rustc slowtest.rs --test and run with RUST_TEST_THREADS=1 ./slowtest.

I can't think of a good way to solve the multithreaded case, without using fancier terminal features to indicate which tests are running, and then rewriting the screen to fill in the results as they finish.

[viraptor]

Ah, that's actually enough to be a viable workaround for me. Maybe there could be some better doc about it (I googled for this and found nothing), but otherwise I'm fine with just using ...THREADS=1.

[huonw]

FWIW< it and a few other things are mentioned in the --help of a test runner (e.g. compiled manually with rustc --test, or just running cargo test -- --help).

[nagisa]

Conflicts with another want to invert status and filename

[dtolnay]

I think there is a lot of room for improvement in the cargo test experience. I am closing this issue because I don't believe we need to track this aspect of it individually. As Huon wrote in #30047 (comment), doing this correctly would involve bringing in some fancier terminal features than what cargo test currently is built on. At that point I would prefer to take the next step and reimagine how cargo test would work in an ideal world -- a bit like what has been done for error messages over the past year. It would be so wonderful if someone takes the initiative to come up with some design proposals. The RFCs repo or the users forum would be the place to follow up.