by sunshowers
6 subcomments
- 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.
- The "execution model" page[1] is documentation at its best!
It answered 90% of the questions I had at the monent. Thank you!
[1] https://nexte.st/docs/design/how-it-works/
- 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.
Discussion thread on gh: https://github.com/nextest-rs/nextest/discussions/3330
by satvikpendem
0 subcomment
- I love nextest, it's been great. This along with bacon catches a lot of issues.
- I love nextest. without it my CI could take hours
https://github.com/tsz-org/tsz/actions/runs/29002057457/job/...
watch it running 32.5k unit tests without breaking a sweat!
- the execution model of cargo-nextest makes my test suite extremely slow to run - Most of my tests rely on postgres. Since cargo-nextest uses a separate process per test, there is no efficient way to share the connection pool.
- I somehow tried to make sense of the name as a superlative form of "next". Perhaps next-test would have been fine?
- 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?
- Anybody using this in production?
edit: Thanks, will try!
Hacker News