Menu
Use when measuring or improving test coverage for a Rust crate. Focus on behavior, invariants, edge cases, unsafe contracts, and regression protection. Do not add shallow tests whose only purpose is to execute lines.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use when porting a C++ implementation to Rust and you need confidence the port is behavior-equivalent. Guides the full workflow — establish a C++ baseline, inventory every external or semantically observable value selected as in-scope by the port-equivalence contract, define that fail-closed contract and a state machine, instrument both sides, port to Rust, then check contract/state-machine conformance and trace/outcome/side-effect equivalence with field-specific numeric policies, complete contract coverage, comparator mutation audit, failure triage, and regression tests.
Use whenever writing, reviewing, or generating Rust code — hardening is the default for all Rust, not just production. Enforces a zero-warning / zero-clippy-finding build, bans panicking constructs (unwrap/expect/panic/indexing/slicing) in non-test code, forbids silently-overflowing arithmetic and lossy `as` casts, and requires runtime failures from arithmetic, indexing, conversion, and other fallible operations to propagate as Result unless local recovery completes the documented contract. Also bans erasing failures through underscore bindings, default substitution, Result-to-Option conversion, or ignored overflow flags, and requires rustfmt. Lint suppression is the rare, self-cleaning exception: `#[expect(reason=…)]` over `#[allow]`, at the narrowest scope, only from an explicit production allowlist — while generated code and test code (#[cfg(test)], tests/, benches/, examples/) may relax freely.
Use when implementing or writing Rust code for real-time systems where predictable WCET matters. Apply to RT-critical paths such as ISRs, schedulers, drivers, packet fast paths, async poll loops, control loops, allocators, and synchronization code. Prefer bounded, allocation-free, panic-free, blocking-free designs over fast average-case code. For reviewing existing patches or PRs, use rust-realtime-review instead.
Use when reviewing Rust patches, PRs, or files for real-time safety, WCET predictability, bounded execution, allocation-free RT paths, panic-free RT paths, synchronization risks, async poll bounds, data-structure predictability, and residual timing risks. Use quick review for normal patches and WCET audit mode for deeper timing-bound analysis.
Use when writing, reviewing, or generating Rust code that calls C (or C that is called from Rust) over FFI — extern "C" declarations, unsafe wrappers, pointer/struct marshaling, or the C side of a Rust binding. Enforces the 26 FFI soundness rules so foreign data and pointers are validated against Rust's safety invariants.
| name | rust-coverage-meaningful-tests |
| description | Use when measuring or improving test coverage for a Rust crate. Focus on behavior, invariants, edge cases, unsafe contracts, and regression protection. Do not add shallow tests whose only purpose is to execute lines. |
Improve the Rust crate's test suite using coverage as a diagnostic map, not as the objective.
A good outcome is not "higher coverage" by itself. A good outcome is:
Never add tests that merely call functions to increase line coverage.
Every new test must have an oracle: an assertion, expected error, invariant check, round-trip property, reference-model comparison, panic expectation, UB check, or regression condition.
Bad:
#[test]
fn covers_parse() {
let _ = parse("123");
}
Good:
#[test]
fn parse_rejects_overflowing_u32() {
let err = parse_u32("4294967296").unwrap_err();
assert_eq!(err.kind(), ParseErrorKind::Overflow);
}
Use cargo llvm-cov as the default coverage tool.
Useful commands:
cargo test --workspace --all-features
cargo llvm-cov --workspace --all-features --html
cargo llvm-cov --workspace --all-features --lcov --output-path lcov.info
If the project uses nextest:
cargo llvm-cov nextest --workspace --all-features
If doctests are important, include them explicitly. On some setups this may require nightly:
cargo +nightly llvm-cov --workspace --all-features --doc
For test quality beyond coverage, consider:
cargo mutants
cargo +nightly miri test
cargo fuzz run <target>
These are not bundled with the toolchain; install them first if needed:
cargo install cargo-mutants
rustup +nightly component add miri
cargo install cargo-fuzz
Use these selectively. Do not block ordinary development on long fuzz or mutation campaigns unless the user asks for it.
Run:
cargo test --workspace --all-features
cargo llvm-cov --workspace --all-features --html
cargo llvm-cov runs the test binaries itself (under instrumentation, so it recompiles). The preceding cargo test is only a fast check that the suite passes before you spend time on the instrumented run.
If the crate has feature combinations, also inspect:
cargo test --workspace --no-default-features
cargo test --workspace --all-features
For crates with meaningful feature matrices, test the smallest important combinations rather than every possible combination.
Do not simply sort by lowest percentage.
Prioritize uncovered code in this order:
Low coverage in dead, deprecated, debug-only, or trivial forwarding code is less important.
For each uncovered high-risk region, write a compact note:
Target:
Risk:
Missing behavior:
Test type:
Oracle:
Expected failure if bug exists:
Example:
Target: src/ring.rs RingBuffer::push/pop wraparound
Risk: off-by-one bug at capacity boundary
Missing behavior: full -> pop -> push -> order preserved
Test type: unit + property test
Oracle: compare against VecDeque model
Expected failure if bug exists: observed sequence differs from model
Only implement tests that have a clear oracle.
Use ordinary example tests for fixed edge cases.
Use property tests when many inputs share the same invariant:
Use regression tests when a specific bug was fixed:
Use fuzzing when input shape is complex or adversarial:
Use Miri when unsafe code, aliasing, initialization, pointer arithmetic, or layout assumptions are involved.
Use mutation testing when coverage is high but confidence is low.
Good tests should usually check at least one of these:
A test that only verifies "this function runs" is usually not enough.
Prefer testing through public or crate-visible APIs.
Private helper tests are acceptable when:
Do not make private functions public just to test them.
Exercise errors deliberately:
Assert the error category, not only is_err().
Prefer:
assert!(matches!(result, Err(Error::InvalidHeader { .. })));
over:
assert!(result.is_err());
Always consider:
For every safe abstraction containing unsafe code, identify its safety contract.
Test:
Send / Sync expectations, if relevant;Run at least the relevant tests under Miri:
cargo +nightly miri test
If Miri does not support part of the crate, isolate smaller tests or mark unsupported tests with #[cfg_attr(miri, ignore)].
For concurrent code, normal tests are weak.
Prefer:
Never treat a stress test as proof of correctness.
Good parser tests include:
For binary formats, test exact bytes where stable.
Coverage with --all-features can hide bugs in --no-default-features.
Run important feature modes separately:
cargo test --workspace --no-default-features
cargo test --workspace --all-features
If the crate supports no_std, do not accidentally add tests that require std in library code.
Use property tests for invariants, not random examples.
Example:
use proptest::prelude::*;
proptest! {
#[test]
fn normalize_is_idempotent(input in ".*") {
let once = normalize(&input);
let twice = normalize(&once);
prop_assert_eq!(once, twice);
}
}
For data structures, compare against a simple model:
use proptest::prelude::*;
use std::collections::VecDeque;
proptest! {
#[test]
fn ring_buffer_matches_vecdeque(ops in proptest::collection::vec(0u8..=2, 0..100)) {
let mut rb = RingBuffer::with_capacity(8);
let mut model = VecDeque::new();
for op in ops {
match op {
0 => {
if model.len() < 8 {
let value = model.len() as u32;
prop_assert_eq!(rb.push(value), Ok(()));
model.push_back(value);
}
}
1 => {
prop_assert_eq!(rb.pop(), model.pop_front());
}
_ => {
prop_assert_eq!(rb.len(), model.len());
prop_assert_eq!(rb.is_empty(), model.is_empty());
}
}
}
}
}
Keep generated inputs small at first. Increase size only after the test is stable.
When fixing a bug, add the smallest failing case.
#[test]
fn parse_rejects_trailing_bytes_after_valid_header() {
let input = b"HEADER\0unexpected";
let err = parse_header(input).unwrap_err();
assert!(matches!(err, ParseError::TrailingBytes { offset: 7 }));
}
A regression test should fail on the old code and pass on the fixed code.
If possible, confirm this before finalizing.
Coverage shows that code was executed. Mutation testing helps check whether assertions detect behavioral changes.
Run:
cargo mutants
Use mutation results to identify tests that are too weak.
If a mutant survives, do not blindly add an assertion. First ask:
Sometimes the right fix is deleting unreachable code, not adding a test.
Avoid excluding code from coverage unless there is a strong reason.
Acceptable exclusions may include:
When excluding code, leave a short reason.
Do not exclude hard-to-test logic just to improve the coverage percentage.
Do not add:
assert!(true);
Do not add tests that only call getters without checking behavior.
Do not assert unstable debug strings unless the debug output is part of the contract.
Do not overfit to the current implementation.
Do not make tests depend on hash map iteration order unless the order is guaranteed.
Do not add sleeps to "fix" flaky async or concurrency tests unless there is no alternative.
Do not weaken the API or expose internals just to test them.
Do not update snapshots without inspecting the semantic diff.
Do not accept higher coverage if the new tests would still pass after deleting the important assertion.
Before finishing, run the relevant subset:
cargo fmt --all -- --check
cargo clippy --workspace --all-features --all-targets -- -D warnings
cargo test --workspace --all-features
cargo llvm-cov --workspace --all-features --summary-only
If the project uses nextest:
cargo llvm-cov nextest --workspace --all-features
If unsafe code was touched or tested:
cargo +nightly miri test
If property tests were added, make sure failures are reproducible and no excessive cases make CI slow.
Summarize:
Do not report coverage as the only success criterion. Emphasize the new behavioral guarantees.