# 测试驱动开发 ## 概述适用于所有 TDD 工作流程的一项技能。使用现有存储库模式强制执行测试优先开发。三种输入模式处理不同的入口点——规范、任务文件或临时描述——但核心循环始终是红色→绿色→重构。 ## 输入模式检测输入类型并遵循相应的模式： ### 模式 A：来自规范 (`.spec.md`) 当输入引用具有给定/何时/然后接受标准的“.spec.md”文件时使用。 1. **定位并解析**规范文件 - 提取所有给定/何时/那么三元组 2. **为每个标准生成一个测试存根**，其中包含 `todo!()` 主体： /// 规范：<规范文件> — 标准 # /// 给定<给定文本> /// 当<当文本>时 /// 然后<然后文本> #[测试] fn <规格名称>_criterion__() { todo!("实现："); } 3. **验证存根编译**但失败：`cargo test --no-run -p ` 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“板条箱/*/tests/*.rs” rg -n "#\[cfg\(test\)\]" 箱子/ 阅读目标代码附近的2-3个相关测试文件。镜子： * 测试模块布局、命名和断言风格 * 夹具助手和测试实用程序 * 使用“tempfile”、场景或工具 ## TDD 周期 ### 1) 红色 — 测试失败 * 为所需的确切行为编写测试 * 运行测试以确认失败**出于正确的原因** * 如果测试通过但没有实现，则测试是错误的 ### 2) 绿色 — 最低限度实施 * 编写最少的代码使测试通过 * 在此步骤中没有额外的功能或重构 ### 3) 重构 — 清理 * 改进实施和测试，同时保持测试绿色 * 与周围的代码库约定保持一致 * 每次更改后重新运行测试 ## Proptest 指南仅当满足以下所有条件时才使用“proptest”： * 函数是纯粹的（没有 I/O、没有时间、没有全局变量） * 给定输入的确定性输出 * 重要的输入空间或边缘情况测试！ { #[测试] fn round_trip(输入“[a-z0-9]{0,32}”){ 让编码 = 编码(input.as_str()); 让解码=解码(&编码).expect(“应该解码”); prop_assert_eq!(解码，输入); } } 如果没有充分的理由，不要将 proptest 作为新的依赖项引入。 ## 背压集成在完成事件中包含覆盖证据： ralph 发出“build.done”“测试：通过，lint：通过，类型检查：通过，审核：通过，覆盖率：通过（82%）” 在可行的情况下运行“cargo tarpaulin --out Html --output-dircoverage --skip-clean”。如果无法进行覆盖，请说明原因并提供有针对性的测试证据。 ## 测试地点规则 * Spec 映射到单个模块 → 内联 `#[cfg(test)]` 测试 * 规范跨越多个模块 → 在 `crates//tests/` 中进行集成测试 * CLI 行为 → `crates/ralph-cli/tests/` * 遵循目标板条箱中的现有模式 ## 反模式 * 在测试之前编写实现 * 生成无需实施即可通过的测试 * 从其他板条箱复制测试而不适应本地模式 * 当简单的示例测试就足够时添加 proptest * 发出没有覆盖证据的完成事件

测试驱动开发

包含技能