rust-test

Use this skill when the user asks to add, fix, refactor, audit, or explain Rust tests or Rust test strategy. It is especially relevant for generated output, diagnostics, CLI output, serialization, parsers, proc macros, fixture-heavy tests, public documentation examples, fuzz/property validation, async or concurrent behavior, unsafe or FFI-heavy code, feature-flag, target-specific, or MSRV-sensitive behavior, flaky tests, performance-sensitive code, Cargo test command selection, coverage/mutation evidence, and snapshot review workflows.

Operating principle

Tests should express the contract clearly and fail with useful diffs. Match the test type to the contract being protected: unit tests for narrow logic, integration/e2e tests for public workflows and real boundaries, doctests for public examples, compile-fail/UI tests for compiler-facing contracts, snapshots/goldens for reviewable deterministic output, property/fuzz tests for broad input spaces, async/concurrency tests for task lifecycle and synchronization behavior, unsafe-code validation for invariants the type system cannot prove, and benchmarks for performance behavior. Prefer the repository's existing test conventions. Do not silently introduce new dev-dependencies, test runners, fuzzers, benchmark harnesses, async runtimes, Miri/sanitizer/loom gates, or snapshot tools unless the repository already uses them or the user explicitly asks to standardize on them.

Refuse mock-object tests that program expectations for collaborator calls and then verify call arguments, counts, or ordering. They couple tests to implementation choreography, can fail during behavior-preserving refactors, and can pass while the public outcome is wrong. If a user asks for this style, explain the refusal briefly and implement or propose a contract-focused alternative instead. Prefer the smallest real integration/e2e seam that proves public behavior. When a real boundary is impractical, a deterministic stub or lightweight fake may control inputs or provide an in-memory implementation, but assertions must target observable state, outputs, artifacts, or public protocol effects rather than calls into the double. Do not add a mocking framework, extend mock expectations already present, or disguise a spy as a fake. Do not rewrite unrelated existing mocks unless they are in the requested scope.

Idiomatic Rust requirement

All test code, helpers, harness examples, and recommendations must use idiomatic Rust for the repository's edition and MSRV, not merely compile.