cargo-nextest vs cargo test: Rust Test Runners
Pick cargo test for the zero-install built-in runner that covers all test types including doctests; pick cargo-nextest for faster parallel runs, per-test process isolation, retries, and better CI reporting.
cargo test is Rust s built-in test runner: it compiles and runs unit, integration, and documentation tests with no extra tooling. cargo-nextest is a third-party runner that re-architects test execution: it runs each test in its own process for isolation, parallelizes aggressively, and adds CI-friendly features like retries, partitioning, and clearer output. They are complementary, since nextest does not run doctests.
| cargo-nextest | cargo test | |
|---|---|---|
| Install | Separate (cargo install/binstall) | Built into Cargo |
| Execution | One process per test | Threads within a binary |
| Speed | Often faster on large suites | Baseline |
| Doctests | Not run (use cargo test) | Yes |
| CI features | Retries, partitioning, JUnit output | Basic output |
| Output | Concise, per-test status | Standard libtest output |
Where each genuinely wins
cargo test wins on zero setup and completeness: it is always available and is the only one that runs doctests. cargo-nextest wins on large suites and CI: per-test process isolation prevents one test from poisoning another s state, it parallelizes well, and features like automatic retries for known-flaky tests, test partitioning across runners, and JUnit XML output make CI faster and easier to read.
In CI
On big test suites, nextest s parallelism and partitioning can shard tests across multiple runners and cut wall-clock time, and its JUnit output plugs into CI test reporting. A common pattern is to run cargo nextest run for unit/integration tests and cargo test --doc separately for doctests, getting the speed of nextest without losing doctest coverage.
Honest caveats
nextest is an extra dependency to install and pin, and because it skips doctests you still need cargo test for those. Per-test process isolation is great for correctness but has process-spawn overhead, so on very small suites the built-in runner may be just as quick. For most large projects nextest s gains outweigh this.
The verdict
Use cargo test for small projects and to run doctests. Use cargo-nextest for large suites in CI where parallelism, isolation, retries, and JUnit reporting pay off, and keep a separate doctest step.