名称： test-driven-development
描述： 统一TDD技能，支持三种输入模式——基于规范、基于任务或基于描述。使用仓库模式强制执行测试优先开发，提供属性测试指导和背压集成。
type: anthropic-skill
版本： "1.0"

测试驱动开发

概述

一个技能覆盖所有TDD工作流。利用现有仓库模式强制执行测试优先开发。三种输入模式处理不同的切入点——规范文件、任务文件或临时描述——但核心循环始终是：红 → 绿 → 重构。

输入模式

检测输入类型并遵循相应模式：

模式A：基于规范 (.spec.md)

当输入引用包含 Given/When/Then 验收标准的 .spec.md 文件时使用。

1. 定位并解析 规范文件——提取所有 Given/When/Then 三元组
2. 为每个标准生成测试桩，使用 todo!() 占位：
   rust /// 规范: <spec-file> — 标准 #<N> /// Given <给定条件> /// When <操作> /// Then <预期结果> #[test] fn <spec_name>_criterion_<N>_<slug>() { todo!("实现: <预期结果>"); }
3. 验证桩代码可编译但测试失败：cargo test --no-run -p <crate>
4. 进入 TDD 循环 使测试通过

编程支持： ralph_core::preflight::{extract_acceptance_criteria, extract_criteria_from_file, extract_all_criteria} 可从规范文件中解析标准。

模式B：基于任务 (.code-task.md)

当输入引用 .code-task.md 文件或特定实现任务时使用。

1. 阅读任务 并识别验收标准或需求
2. 发现模式 (参见 模式发现)
3. 设计测试场景，覆盖正常操作、边界情况和错误条件
4. 为所有需求编写失败测试，先于任何实现
5. 进入 TDD 循环

模式C：基于描述

用于没有规范或任务文件的临时任务。

1. 从描述中澄清需求
2. 发现模式 (参见 模式发现)
3. 针对描述的行为编写失败测试
4. 进入 TDD 循环

模式发现

在编写测试前，发现现有约定：

rg --files -g "crates/*/tests/*.rs"
rg -n "#\[cfg\(test\)\]" crates/

阅读目标代码附近的 2-3 个相关测试文件。模仿：
- 测试模块布局、命名和断言风格
- 夹具助手和测试工具
- tempfile、场景或测试框架的使用

TDD 循环

1) 红 —— 失败测试

• 为所需的确切行为编写测试
• 运行测试以确认 因正确原因 失败
• 如果测试未经实现就通过，则测试有误

2) 绿 —— 最小实现

• 编写使测试通过的最少代码
• 此步骤中不添加额外功能或重构

3) 重构 —— 清理

• 在保持测试通过的同时改进实现和测试
• 与周围代码库的约定保持一致
• 每次更改后重新运行测试

属性测试指导

仅当满足 所有 以下条件时使用 proptest：
- 函数是纯函数（无 I/O、无时间依赖、无全局变量）
- 给定输入具有确定性输出
- 输入空间复杂或存在边界情况

proptest! {
    #[test]
    fn round_trip(input in "[a-z0-9]{0,32}") {
        let encoded = encode(input.as_str());
        let decoded = decode(&encoded).expect("应该解码成功");
        prop_assert_eq!(decoded, input);
    }
}

没有充分理由时，不要引入 proptest 作为新依赖。

背压集成

在完成事件中包含覆盖率证据：

ralph emit "build.done" "tests: pass, lint: pass, typecheck: pass, audit: pass, coverage: pass (82%)"

可行时运行 cargo tarpaulin --out Html --output-dir coverage --skip-clean。如果无法运行覆盖率测试，请说明原因并包含针对性的测试证据。

测试位置规则

• 规范映射到单个模块 → 内联 #[cfg(test)] 测试
• 规范跨越多个模块 → 集成测试位于 crates/<crate>/tests/
• CLI 行为 → crates/ralph-cli/tests/
• 遵循目标 crate 中的现有模式

反模式

• 在编写测试之前先写实现
• 生成未经实现就能通过的测试
• 从其他 crate 复制测试而不适配本地模式
• 在简单示例测试足够时添加属性测试
• 发出没有覆盖率证据的完成事件