alt Hacker NewsThanks 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.
Replies
Big fan of nextest and this is my first time seeing this site. I'll be real I feel a bit ridiculous commenting this but you might want to consider rephrasing this:
>Treat tests as cattle, not pets. Detect and terminate slow tests.
Not sure saying, "hey, treat your tests as an animal you can kill at will" paints the right image.
Thank you very much for developing nextest. It is what allows our projects like rama [1] to run thousands and thousands of tests in a blink of an eye! Keep it up!
Thank you! It's great.
Hey, I love nextest. But, perhaps because of the one-process per test approach, endpoint security solutions like CrowdStrike Falcon or Palo Alto Cortex tend to make computers hang whenever tests kick-in. I would love if you were able to introduce a workaround, because none of those companies will fix their stuff. I am guessing a possible mitigation would be to have stagger the first invocation of any large test binary, but I haven't had a chance to dig deep into this issue.
Have there been any discussions about upstreaming this into cargo proper? Are there any significant downsides to nextest compared to its predecessor?
First, I like how all this works, it's great.
Can you run tests serially in the (horrible) case when tests need to build on one another?
How are you querying for the tests? Is that just built into rust's test stuff?
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.