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.
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.
This is from the Kubernetes saying of "treat servers like cattle, not pets". Of course, some people like me keep cattle as pets, but then again I also name my servers, even the virtual or containerised ones.
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!
Super happy user here! It's an excellent piece of engineering.
We're running a fork that supports a "sidecar" server for running multiple integration tests against. So if any tests that need the server are included, it spawns the server, runs the integration tests, and then shuts it down. By re-using the same server we speed up our runs tremendously.
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.
seems like `cargo nextest run` just runs `--lib` tests by default? however, `cargo test` is not so slow if you do `cargo test --lib`. how do I get nextest to execute the doc tests, too?
Yes we use it for rama [1]. You can check its justfile and CI workflow file how we use it. Those run thousands and thousands of tests thx to nextest and what feels like instantly (once compiled).
Large projects build with rama use it as well. But those are proprietary from partners so sadly cannot share those.
>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.
edit: Updated to "Detect and handle slow tests". Thanks again!
[1] https://ramaproxy.org
[1] https://nexte.st/docs/design/how-it-works/
[2] https://nexte.st/docs/design/why-process-per-test/
We're running a fork that supports a "sidecar" server for running multiple integration tests against. So if any tests that need the server are included, it spawns the server, runs the integration tests, and then shuts it down. By re-using the same server we speed up our runs tremendously.
Discussion thread on gh: https://github.com/nextest-rs/nextest/discussions/3330
It answered 90% of the questions I had at the monent. Thank you!
[1] https://nexte.st/docs/design/how-it-works/
https://github.com/tsz-org/tsz/actions/runs/29002057457/job/...
watch it running 32.5k unit tests without breaking a sweat!
edit: Thanks, will try!
Large projects build with rama use it as well. But those are proprietary from partners so sadly cannot share those.
[1]: https://github.com/plabayo/rama