Look, you can either let people make a living and manage their own lives while contributing to society, or you can not let them make a living and ensure they're housed and fed. You can't be angry at A and also be angry at B.
Nextest does run tests in lexicographic (binary, test name) order by default, so first executions tend to be staggered. Unfortunately this is a known problem that is much larger than nextest, and it is why Windows introduced Dev Drive with a mode to disable AV/EDR on those drives entirely.
I wish I had a better answer here — it is frustrating how poorly behaved the EDR stuff tends to be. Maybe I should try and network a bit to get in touch with the people working on this stuff. (Planning to be at DEF CON this year, so come find me if you work on this stuff and will be there!)
From what I can tell, a big part of the problem in Europe is that people seeking asylum are prohibited from making a living (due to widespread belief in the lump of labor fallacy) and so have to be dependent on welfare.
The benchmarks are against non-doctest cargo test runs. (But you should measure against your own project, of course!) Unfortunately Cargo doesn't provide enough information for nextest to run doctests reliably with.
I think in practice you're right that GitHub Actions' caching slowness can end up dominating performance. I don't have any great tips other than to measure.
> How are you querying for the tests? Is that just built into rust's test stuff?
Just running --list against test binaries.
> Would it be possible to fork the test process? It'd be pretty interesting if you could spawn a test process, and then fork it for each test to save both on memory and any static state stored within the test.
This is possible in principle, but nextest doesn't really inject itself into tests like that (injection can cause reliability issues in practice, and a big focus of nextest is reliability). Forking is also not possible in multithreaded programs.
Thanks! BTW you might enjoy setting CARGO_TERM_COLOR=always in your environment :) dtolnay/rust-toolchain does this automatically but it looks like you aren't using that action.
Thanks for posting about this! I'm the main author of nextest, and it represents my best foot forward for how Rust testing should be done. Happy to answer questions though I might be a bit intermittent.
My successful application took around 12 hours of writing and editing across 3 days, though I was lucky that most of my portfolio was already open source or otherwise public. Some people spend more, some spend less.
It is worth keeping in mind that we write a _lot_. If you don't enjoy the process of writing, you might not like working here.
hn at <username>.io