一键导入
rust-testing
Rust testing patterns including unit tests, integration tests, async testing, property-based testing, mocking, and coverage. Follows TDD methodology.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Rust testing patterns including unit tests, integration tests, async testing, property-based testing, mocking, and coverage. Follows TDD methodology.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
ann-benchmarks フレームワーク規約(algos.yaml/HDF5/Pareto frontier分析)と ANN ベクトル検索の SIMD 距離カーネル最適化における落とし穴パターン(AVX2/AVX-512 ディスパッチャ検証・量子化の数学的等価性確認・部分集合とフルスケールの混同防止)。ArcFlare/NGT/NGTAQ 等の ANN R&D 作業時の参照用。実装作業自体は ann-perf-engineer agent に委譲する。
Use this skill to measure performance baselines, detect regressions before/after PRs, and compare stack alternatives.
Claude API / Anthropic Go SDK usage patterns, prompt caching, streaming, tool use, and model selection for Go applications.
C++ coding standards based on the C++ Core Guidelines (isocpp.github.io). Use when writing, reviewing, or refactoring C++ code to enforce modern, safe, and idiomatic practices.
Deployment workflows, CI/CD pipeline patterns, Docker containerization, health checks, rollback strategies, and production readiness checklists for web applications.
非推奨・後方互換用リダイレクト。旧 dig(コードベース深掘り分析→設計インタビュー→実装計画→自律実行)は swarm-loop に完全統合された。/dig と入力された場合は本ファイルの指示に従い、そのまま swarm-loop skill を 同じ目標・同じ引数で起動すること。dig 独自のロジックはここには存在しない。
| name | rust-testing |
| description | Rust testing patterns including unit tests, integration tests, async testing, property-based testing, mocking, and coverage. Follows TDD methodology. |
| origin | ECC |
Comprehensive Rust testing patterns for writing reliable, maintainable tests following TDD methodology.
Full code examples for every pattern below live in reference.md (same directory) — this file
covers when/why and the core decision criteria; reference.md has the copy-pasteable "how".
#[test] in a #[cfg(test)] module, rstest for parameterized tests, or proptest for property-based testsRED → Write a failing test first
GREEN → Write minimal code to pass the test
REFACTOR → Improve code while keeping tests green
REPEAT → Continue with next requirement
Full step-by-step example (todo!() placeholder → failing test → minimal implementation): see
reference.md#step-by-step-tdd-in-rust.
Each pattern below has full code in reference.md. Use this list to decide which pattern fits,
then jump to the matching section.
reference.md#module-level-test-organization) — put unit
tests in a #[cfg(test)] mod tests block alongside the code they exercise; use super::*.reference.md#assertion-macros) — assert_eq!/assert_ne!/assert!
with custom messages, plus epsilon comparison for floats.Result Returns (reference.md#testing-result-returns) — assert on
matches!(err, Variant(_)) for the error path, and write tests returning
Result<(), Box<dyn Error>> with ? for the success path.reference.md#testing-panics) — #[should_panic] (optionally with
expected = "..."); prefer Result::is_err() assertions when the code returns a Result.reference.md#file-structure, reference.md#writing-integration-tests)
— one file per test binary under tests/, with shared helpers in tests/common/mod.rs.reference.md#with-tokio) — #[tokio::test]; use
tokio::time::timeout to assert on timeout behavior instead of relying on real delays.rstest (reference.md#parameterized-tests-with-rstest) —
#[case(...)] for table-driven inputs, #[fixture] for shared setup.reference.md#test-helpers) — factory functions (e.g. make_user) inside the
tests module to remove setup duplication.proptest (reference.md#basic-property-tests,
reference.md#custom-strategies) — proptest! { #[test] fn(...) } for roundtrip/invariant
checks over generated inputs; custom Strategy impls for domain-shaped data (e.g. emails).mockall (reference.md#trait-based-mocking) — #[automock] on a small
trait, then MockX::new() with .expect_*().with(...).returning(...) in the test.reference.md#executable-documentation) — executable examples in /// doc
comments; use no_run for examples that shouldn't actually execute in CI.reference.md#benchmarking-with-criterion) — [[bench]] in
Cargo.toml with harness = false, criterion_group!/criterion_main!, black_box to
prevent constant-folding.# Install: cargo install cargo-llvm-cov (or use taiki-e/install-action in CI)
cargo llvm-cov # Summary
cargo llvm-cov --html # HTML report
cargo llvm-cov --lcov > lcov.info # LCOV format for CI
cargo llvm-cov --fail-under-lines 80 # Fail if below threshold
| Code Type | Target |
|---|---|
| Critical business logic | 100% |
| Public API | 90%+ |
| General code | 80%+ |
| Generated / FFI bindings | Exclude |
cargo test # Run all tests
cargo test -- --nocapture # Show println output
cargo test test_name # Run tests matching pattern
cargo test --lib # Unit tests only
cargo test --test api_test # Integration tests only
cargo test --doc # Doc tests only
cargo test --no-fail-fast # Don't stop on first failure
cargo test -- --ignored # Run ignored tests
DO:
#[cfg(test)] modules for unit testsassert_eq! over assert! for better error messages? in tests that return Result for cleaner error outputDON'T:
#[should_panic] when you can test Result::is_err() insteadsleep() in tests — use channels, barriers, or tokio::time::pause()GitHub Actions example (checkout → stable toolchain with clippy+rustfmt → cargo fmt --check →
cargo clippy -- -D warnings → cargo test → cargo-llvm-cov coverage threshold): see
reference.md#ci-integration.
Remember: Tests are documentation. They show how your code is meant to be used. Write them clearly and keep them up to date.