Comments

Hacker News

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.

by mollerhoj

I somehow tried to make sense of the name as a superlative form of "next". Perhaps next-test would have been fine?

by patates

Anybody using this in production?

edit: Thanks, will try!

by esafak

I love nextest, it's been great. This along with bacon catches a lot of issues.

by satvikpendem

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 jtwaleson

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.

by sunshowers

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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?
  • Anybody using this in production?

    edit: Thanks, will try!

  • 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!

  • I love nextest, it's been great. This along with bacon catches a lot of issues.
  • 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

  • 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/

  • 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.