Rtk Tdd

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

Patterns by Code Type

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.

RTK Testing Patterns Reference

Untested Modules Backlog

Prioritized by testability (pure functions first, I/O-heavy last).

High Priority (pure functions, trivial to test)

Medium Priority (need tempfile or parsed input)

Low Priority (heavy I/O, CLI wiring)

RTK Test Patterns

Pattern 1: Filter Function (most common in RTK)

#[test]
fn test_FILTER_happy_path() {
    // Arrange: raw command output as string literal
    let input = r#"
line of noise
line with relevant data
more noise
"#;
    // Act
    let result = filter_COMMAND(input);
    // Assert: output contains expected, excludes noise
    assert!(result.contains("relevant data"));
    assert!(!result.contains("noise"));
}

Used in: git.rs, grep_cmd.rs, lint_cmd.rs, tsc_cmd.rs, vitest_cmd.rs, pnpm_cmd.rs, next_cmd.rs, prettier_cmd.rs, playwright_cmd.rs, prisma_cmd.rs

Pattern 2: Pure Computation

#[test]
fn test_FUNCTION_deterministic() {
    assert_eq!(truncate("hello world", 8), "hello...");
    assert_eq!(truncate("short", 10), "short");
}

Used in: gh_cmd.rs (truncate), utils.rs (truncate, format_tokens, format_usd)

Pattern 3: Validation / Security

#[test]
fn test_VALIDATOR_rejects_injection() {
    assert!(!is_valid("malicious; rm -rf /"));
    assert!(!is_valid("../../../etc/passwd"));
}

Used in: pnpm_cmd.rs (is_valid_package_name)

Pattern 4: ANSI Stripping

#[test]
fn test_strip_ansi() {
    let input = "\x1b[32mgreen\x1b[0m normal";
    let output = strip_ansi(input);
    assert_eq!(output, "green normal");
    assert!(!output.contains("\x1b["));
}

Used in: vitest_cmd.rs, utils.rs

Test Skeleton Template

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_FUNCTION_happy_path() {
        // Arrange
        let input = r#"..."#;
        // Act
        let result = FUNCTION(input);
        // Assert
        assert!(result.contains("expected"));
        assert!(!result.contains("noise"));
    }

    #[test]
    fn test_FUNCTION_empty_input() {
        let result = FUNCTION("");
        assert!(...);
    }

    #[test]
    fn test_FUNCTION_edge_case() {
        // Boundary conditions: very long input, special chars, unicode
    }
}