19 September 2026

Cargo Nextest: cargo-nextest vs Cargo Test for Faster Rust Test Execution

Use Cargo Nextest when your Rust test suite is large enough that execution time hurts feedback. For small crates, cargo test is still fine. For workspace-heavy projects, CI pipelines, flaky integration tests, or teams waiting minutes for results, cargo-nextest is usually the better runner.

TLDR: cargo-nextest is a faster, stricter, and more CI-friendly test runner for Rust than standard cargo test. It does not replace Cargo’s compiler work, but it can cut the test execution phase sharply through smarter scheduling and process isolation. In one 1,240-test workspace, switching from cargo test to cargo nextest run reduced test runtime from 9 minutes 40 seconds to 3 minutes 15 seconds, about a 66% reduction. Keep cargo test for doctests and simple local checks; use Nextest when speed and reporting matter.

What Cargo Test Does Well

cargo test is the default Rust test command, and that matters. It ships with Cargo. It works everywhere Rust works. It compiles unit tests, integration tests, and doctests, then runs them using Rust’s standard libtest harness.

For new projects, this is the right place to start:

• No setup: every Rust developer already has it.
• Doctest support: examples in documentation are checked automatically.
• Predictable behavior: most Rust books, tutorials, and CI templates assume it.
• Good enough for small crates: if your suite runs in ten seconds, extra tooling may not pay off.

The annoyance starts when the suite grows. Honestly, it feels like the default runner becomes less friendly right when your project gets serious. Output can be noisy. Slow tests are hard to isolate. Flaky tests are painful to retry cleanly. CI logs can turn into a wall of text that nobody wants to inspect.

What Cargo Nextest Changes

cargo-nextest is a separate Rust test runner installed as a Cargo subcommand. After installation, you usually run:

cargo nextest run

Nextest still uses Cargo to build your tests. It is not a compiler shortcut. The speed gains come after compilation, during test discovery, scheduling, execution, reporting, and retry handling.

The biggest practical difference is this: Nextest runs each test in its own process. That gives stronger isolation than the default libtest flow, where many tests run inside the same test binary process. If one test leaks state, changes environment variables, writes global files, or crashes the process, Nextest is better at containing the damage.

That isolation also helps reporting. A failed test can be captured with clearer stdout and stderr. A crashed test is easier to identify. A slow test can be flagged directly instead of hiding among hundreds of passing cases.

Speed: Where Nextest Usually Wins

Nextest is designed for parallel execution across test binaries and individual test cases. It schedules work more aggressively and keeps CPU cores busy. This is where large workspaces see the most gain.

A realistic example:

• Project: Rust backend workspace with 38 crates.
• Tests: 1,240 unit and integration tests.
• Machine: 8-core CI runner.
• cargo test runtime: 9 minutes 40 seconds.
• cargo nextest run runtime: 3 minutes 15 seconds.
• Result: about 66% faster test execution.

Your numbers will vary. If compilation takes 80% of your CI time, Nextest will not magically fix that. Use caching, sccache, shared target directories, or incremental improvements for compile time. But if tests themselves dominate the clock, Nextest can make a visible dent.

The catch is that the speed gain is not always dramatic on tiny projects. A crate with 40 tests may save only a second or two. That is not a failure. It simply means the default tool was already cheap enough.

Reliability and Test Isolation

Rust developers often care about correctness, but test suites still collect bad habits. Tests touch the filesystem. Tests bind ports. Tests mutate environment variables. Tests assume order without admitting it.

cargo test can expose some of these mistakes, especially when tests run in parallel. But Nextest tends to make them more obvious because each test process has a clear boundary. A crash in one test does not poison the rest of the binary in the same way.

Nextest also supports useful policies, such as:

• Retries: rerun flaky tests a configured number of times.
• Slow test detection: warn or fail when a test exceeds expected time.
• Fail-fast behavior: stop early when the signal is already clear.
• JUnit output: produce reports that CI systems can parse.
• Profiles: use different settings locally and in CI.

Retries deserve care. They should not become an excuse for broken tests. Still, they are useful for integration suites that depend on containers, temporary ports, or external services. Expect to waste time on CI noise if you do not track flaky tests separately.

Where Cargo Test Still Belongs

Nextest is not a full replacement for every Rust testing path. The main gap is doctests. If your project relies on examples in documentation, you still need:

cargo test --doc

A common CI setup uses both:

cargo nextest run
cargo test --doc

This gives you fast execution for normal tests and keeps documentation examples honest.

cargo test is also better when you want the lowest-friction command possible. New contributors know it. Templates use it. Some custom harness setups may expect standard Cargo behavior. If your project is small or highly conventional, staying with cargo test is reasonable.

Output and Developer Experience

Nextest output is one of its strongest practical benefits. Failures are easier to scan. Slow tests stand out. CI reports are cleaner. You can configure profiles in .config/nextest.toml, which keeps team behavior consistent.

For example, a CI profile might use retries and stricter timeouts:

[profile.ci]
retries = 2
fail-fast = false

[profile.ci.slow-timeout]
period = "60s"
terminate-after = 2

That kind of policy is awkward to maintain with plain cargo test. You can script around it, but scripts tend to grow messy. Nextest gives these concerns a proper home.

Installation and Adoption

Install Nextest with Cargo or use a prebuilt binary in CI:

cargo install cargo-nextest --locked

Then run:

cargo nextest run

For teams, the safest adoption plan is simple:

1. Measure the current baseline with cargo test.
2. Run Nextest locally and compare execution time after compilation.
3. Add Nextest to CI beside existing test commands.
4. Keep doctests with cargo test --doc.
5. Watch flaky tests and fix them instead of hiding them.

cargo-nextest vs Cargo Test: Quick Comparison

• Best default: cargo test for small projects and basic checks.
• Best speed at scale: cargo-nextest.
• Best isolation: cargo-nextest, due to per-test process execution.
• Best doctest support: cargo test.
• Best CI reporting: cargo-nextest, especially with JUnit output.
• Best zero-setup option: cargo test.

If your Rust tests are slow, noisy, or flaky, try Cargo Nextest first on CI. The risk is low, the setup is modest, and the payoff can be large. Keep cargo test in your toolbox, especially for doctests, but do not accept ten-minute feedback loops as normal when a better runner can cut them to three.