HN Debrief

Cargo-nextest: 3x faster than cargo test, per-test isolation, first-class CI

  • Programming
  • Developer Tools
  • Open Source
  • Infrastructure

Cargo-nextest is a Rust test runner built as a `cargo test` alternative. Its core design is process-per-test isolation, which lets it schedule tests more aggressively, contain flaky shared state, and give CI better failure handling and reporting. The pitch is not just raw speed. It is faster, but the bigger claim is that Rust testing works better when each test is treated as an isolated execution unit instead of part of one long-lived process.

If you run substantial Rust test suites in CI, nextest looks mature enough to evaluate now, but you should benchmark it against your own mix of unit, integration, and database-backed tests rather than trusting headline speedups. Watch especially for gaps around doctests, shared-state integration setups, and corporate security software on developer machines or Windows fleets.

Discussion mood

Strongly positive. Most comments came from long-term users who said nextest is excellent, mature, and a major CI speed win, while the few criticisms were practical edge cases rather than doubts about the project itself.

Key insights

  1. 01

    Reliability drove the execution model

    The process-per-test design was chosen to keep the runner out of the test process itself. That rules out clever tricks like preloading and forking a warm process, but it avoids a whole class of reliability problems that come from injecting behavior into tests. The author also notes that forking is not available in multithreaded programs, which makes the obvious optimization less portable and less safe than it sounds.

    If you are comparing test runners, do not judge nextest only on peak throughput. Treat its isolation model as a reliability tradeoff that is likely to pay off in large CI systems where flakiness costs more than a few seconds.

      Attribution:
    • sunshowers #1
  2. 02

    Shared-resource integration tests are the weak spot

    Database-backed and service-backed suites expose where per-test isolation hurts. One commenter said Postgres-heavy tests became extremely slow because each process lost efficient access to a shared connection pool. Another team got around similar overhead by running a reusable sidecar server across multiple integration tests. The author points to test groups for shared resources, but that is not the same as supporting tests that truly depend on building on one another.

    If your Rust suite spends most of its time talking to shared infrastructure, expect to redesign test setup before nextest shines. Audit which tests can be made self-contained and which need grouped execution or service reuse.

      Attribution:
    • mollerhoj #1
    • jtwaleson #1
    • sunshowers #1
  3. 03

    Doctest support is still missing

    This is not a drop-in replacement for every `cargo test` workflow because doctests are still out of reach. The blocker is not just implementation backlog. Cargo does not provide enough information for nextest to run doctests reliably, so this gap is tied to upstream tooling boundaries.

    If you rely on doctests for API correctness or docs quality gates, keep a separate `cargo test` step or another workaround in CI. Do not switch blindly and assume feature parity.

      Attribution:
    • sunshowers #1
    • mattstir #1
  4. 04

    Security agents can erase the performance gains

    Endpoint detection and response products like CrowdStrike Falcon and Palo Alto Cortex can make machines stall when nextest spawns many short-lived processes. The author says nextest already staggers first executions by default, so the remaining pain is largely the behavior of those tools rather than naive scheduling inside nextest. The mention of Windows Dev Drive disabling antivirus and endpoint detection on selected drives underlines how systemic this problem is.

    If your engineers or CI workers run heavy endpoint security software, test nextest in that exact environment before rollout. A process-heavy runner can expose infrastructure bottlenecks that have nothing to do with Rust.

      Attribution:
    • sunshowers #1
    • arw0n #1
  5. 05

    GitHub Actions caching often dominates sharding

    For large suites, the limiting factor may stop being test execution and become GitHub Actions cache overhead. One user asked for sharding advice after landing on a single job because cache restore costs wiped out the gain. The answer was essentially that this is common and must be measured, with another commenter saying they have mostly abandoned GitHub Actions caching because it made jobs slower.

    Before splitting your Rust tests across more CI jobs, measure cache restore and artifact movement time first. You may get better returns from a simpler single-job setup than from elaborate sharding.

      Attribution:
    • mohsen1 #1
    • sunshowers #1
    • evntdrvn #1

Against the grain

  1. 01

    The benchmark framing is narrower than it sounds

    The headline speed comparison does not cover all of `cargo test`. A commenter noticed nextest defaults align with non-doctest runs and asked how to include doctests. The author confirmed the published benchmarks are against non-doctest `cargo test` runs. That does not make the numbers wrong, but it does mean the marketing claim maps to a subset of common usage.

    When evaluating claimed speedups, compare the exact commands you run today, including doctests or other extras. Otherwise you may benchmark against a smaller baseline and overestimate the gain.

      Attribution:
    • jstrong #1
    • sunshowers #1

In plain english

CI ↩
Continuous Integration, automated systems that build and test code changes before or after they are merged.
connection pool ↩
A reusable set of open database connections shared by code so it does not have to reconnect for every operation.
CrowdStrike Falcon ↩
A commercial endpoint security product that monitors systems for threats and can interfere with developer workloads.
doctest ↩
A test extracted from example code in documentation, usually run to verify that docs stay correct and executable.
GitHub Actions ↩
GitHub’s hosted automation service for running builds, tests, and deployment workflows.
Palo Alto Cortex ↩
A family of enterprise security tools from Palo Alto Networks, including endpoint detection products.
Postgres ↩
PostgreSQL, a widely used open source relational database.
sharding ↩
Splitting a test suite or workload across multiple machines or jobs so parts can run in parallel.
sidecar server ↩
A helper service started alongside tests so multiple test cases can share one running dependency instead of each starting its own.
Tokio ↩
A widely used asynchronous runtime and ecosystem for Rust applications.
Windows Dev Drive ↩
A Windows storage feature aimed at developer workloads, including options that reduce antivirus or security scanning overhead.

Reference links

Project documentation

Real-world usage examples

Extensions and open issues