Testing workflow

Rust Testing Workflow

Purpose

Run the narrowest useful Rust tests, explain failures clearly, and keep test layout aligned with Cargo's model.

Cargo test behavior matters because one command can compile and run unit tests, integration tests, documentation tests, and examples. The skill should make that scope explicit instead of treating cargo test as a black box.

Source Check

Use repo-local Rust files, checked-out dependency sources, Dash MCP or Dash HTTP for installed Rust docsets, and then official Rust documentation when Dash/local coverage is missing or stale:

• Cargo tests guide
• cargo test
• The Rust book testing chapter
• Cargo features reference

Translate test behavior into the concrete command and failure mode in the repository.

Test Layout

• Put unit tests near implementation when they need private module access.
• Put integration tests under tests/ when they should use the crate like an external caller.
• Use documentation tests when examples in public API docs should compile and run.
• Use examples/ when sample binaries should compile as part of validation.
• Use feature-gated tests only when the crate's feature matrix is part of the public behavior.

Command Selection

Start narrow, then widen:

cargo test

Target one package in a workspace:

cargo test -p package-name

Run all workspace tests:

cargo test --workspace

Run all targets and features when feature interactions matter:

cargo test --all-targets --all-features

Filter by test name:

cargo test some_test_name

Show test output:

cargo test some_test_name -- --nocapture

Run documentation tests only when public docs are the focus:

cargo test --doc

Failure Triage

Classify failures by the first concrete break:

• compile failure: source, dependency, feature, target, or MSRV problem
• unit test failure: internal behavior changed
• integration test failure: public behavior or crate boundary changed
• doctest failure: public example or documentation drifted
• feature failure: optional dependency or cfg path broke
• workspace failure: package selection, shared dependency, or target matrix issue

Read the first relevant compiler or test error before changing code. Rust output is usually precise; preserve that precision in the user-facing explanation.

Implementation Guidance

• Add tests at the same boundary the user cares about.
• Prefer deterministic tests over sleeps, timing assumptions, or network calls.
• Use temporary directories for filesystem behavior.
• Avoid snapshot tests unless the repo already uses them or the output is intentionally broad.
• Keep error-message assertions focused on stable, user-visible text.

Output Shape

Return:

1. Test scope: package, workspace, target, feature, or doc-test boundary.
2. Commands: exact commands run or recommended.
3. Result: pass, fail, or skipped with the concrete reason.
4. Failure mode: compile, unit, integration, doctest, feature, or workspace issue.
5. Fix direction: the smallest code, test, dependency, or docs change that addresses the failure.

Guardrails

• Do not run broad feature or workspace matrices first when a targeted command proves the change.
• Do not hide compile failures behind test summaries.
• Do not weaken tests to match broken behavior unless the user explicitly approves the behavior change.
• Do not add network-dependent tests without a repo-owned test strategy for them.