L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Développement · SKILL.md

rtk-tdd

rtk-tdd

Enforces TDD (Red-Green-Refactor) for Rust development. Auto-triggers on implementation, testing, refactoring, and bug fixing tasks. Provides Rust-idiomatic testing patterns with anyhow/thiserror, cfg(test), and Arrange-Act-Assert workflow.

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: rtk-tdd description: > Enforces TDD (Red-Green-Refactor) for Rust development. Auto-triggers on implementation, testing, refactoring, and bug fixing tasks. Provides Rust-idiomatic testing patterns with anyhow/thiserror, cfg(test), and Arrange-Act-Assert workflow. allowed-tools:

  • Read
  • Write
  • Edit
  • Bash effort: medium tags: [tdd, testing, rust, red-green-refactor, rtk]

Rust TDD Workflow

Three Laws of TDD

  1. Do NOT write production code without a failing test
  2. Write only enough test to fail (including compilation failure)
  3. Write only enough production code to pass the failing test

Cycle: RED (test fails) -> GREEN (minimum to pass) -> REFACTOR (cleanup, cargo test)

Red-Green-Refactor Steps

1. Write test in #[cfg(test)] mod tests of the SAME file
2. cargo test MODULE::tests::test_name  -- must FAIL (red)
3. Implement the minimum in the function
4. cargo test MODULE::tests::test_name  -- must PASS (green)
5. Refactor if needed, re-run cargo test (still green)
6. cargo fmt && cargo clippy --all-targets && cargo test  (final gate)

Never skip step 2. If the test passes immediately, it tests nothing.

Idiomatic Rust Test Patterns

PatternUsageWhen
Arrange-Act-AssertBase structure for every testAlways
assert_eq! / assert!Direct comparison / booleansDeterministic values
assert!(result.is_err())Error path testingInvalid inputs
Result<()> return typeTests with ? operatorFallible functions
#[should_panic]Expected panicInvariants, preconditions
tempfile::NamedTempFileFile/I/O testsFilesystem-dependent code

Patterns by Code Type

Code TypeTest PatternExample
Pure function (str -> str)Input literal -> assert outputassert_eq!(truncate("hello", 3), "...")
Parsing/filteringRaw string -> filter -> contains/not-containsassert!(filter(raw).contains("expected"))
Validation/securityBoundary inputs -> assert boolassert!(!is_valid("../etc/passwd"))
Error handlingBad input -> is_err()assert!(parse("garbage").is_err())
Struct/enum roundtripConstruct -> serialize -> deserialize -> eqassert_eq!(from_str(to_str(x)), x)

Naming Convention

test_{function}_{scenario}
test_{function}_{input_type}

Examples: test_truncate_edge_case, test_parse_invalid_input, test_filter_empty_string

When NOT to Use Pure TDD

  • Functions calling Command::new() -> test the parser, not the execution
  • std::process::exit() -> refactor to Result first, then test the Result
  • Direct I/O (SQLite, network) -> use tempfile/mock or test the pure logic separately
  • Main/CLI wiring -> covered by integration/smoke tests

Pre-Commit Gate

cargo fmt --all --check
cargo clippy --all-targets
cargo test

All 3 must pass. No exceptions. No #[allow(...)] without documented justification.

Skills enregistrées