Property Tests, Snapshots, Benchmarks, and CI

Rule

Use Nextest as the default workspace runner and add snapshots, property tests, or benchmarks only for a matching behavior or performance need.

Activation

Apply this page when configuring test commands, CI, snapshots, property tests, benchmarks, or release verification.

Why

Specialized tools improve the right tests but add dependencies, review process, and maintenance cost.

Do

• Run cargo nextest run --workspace --all-targets --all-features locally and in CI.
• Keep cargo test for doctests and cases Nextest does not cover.
• Run pinned formatting and Clippy checks alongside tests.
• Use insta for stable complex textual or structured output.
• Commit and review snapshot changes; normalize nondeterministic fields first.
• Use proptest for parsers, round trips, normalization, state machines, and broad invariants.
• Use criterion only for stated performance requirements or regression risks.
• Keep benchmark inputs representative, named, and stable.

Avoid

• Do not add every testing tool by default.
• Do not snapshot simple scalar assertions or raw nondeterministic data.
• Do not accept snapshot changes without review.
• Do not create property generators whose failures cannot be diagnosed.
• Do not treat benchmarks as correctness tests or unstable thresholds as ordinary CI gates.
• Do not let local and CI test sets diverge silently.

Example

cargo +nightly-2026-04-14 fmt --check --all
cargo clippy --locked --workspace --all-targets --all-features -- -D warnings
cargo nextest run --workspace --all-targets --all-features

Exceptions

• Existing projects may keep cargo test until Nextest is adopted deliberately.
• Keep quickcheck where it is already established; prefer proptest for new work.
• Use service load tests when Criterion does not model the real risk.