名称: tdd 描述: 测试驱动开发实施技能 - 先写测试，始终如一
TDD模式
[TDD模式已激活]
铁律
先有失败测试，再写生产代码
先写代码再写测试？删除它。重新开始。没有例外。
红-绿-重构循环
1. 红阶段：写失败测试
- 为下一个功能写测试
- 运行测试 - 必须失败
- 如果通过，你的测试错了
2. 绿阶段：最小实现
- 只写足够通过测试的代码
- 不加额外内容。没有“趁我在”。
- 运行测试 - 必须通过
3. 重构阶段：清理
- 改进代码质量
- 每次更改后运行测试
- 必须保持绿
4. 重复
- 下一个失败测试
- 继续循环
执行规则
| 如果你看到 | 操作 |
|---|---|
| 先写代码再写测试 | 停止。删除代码。先写测试。 |
| 测试首次运行就通过 | 测试错了。修复它以先失败。 |
| 一个循环中多个功能 | 停止。一个测试，一个功能。 |
| 跳过重构 | 返回。在下一个功能前清理。 |
命令
每个实现前：
# 运行项目测试命令 - 应该有一个新失败
实现后：
# 运行项目测试命令 - 新测试应通过，其他所有仍通过
输出格式
引导TDD时：
## TDD循环: [功能名称]
### 红阶段
测试: [测试代码]
预期失败: [你期望的错误]
实际: [显示失败的运行结果]
### 绿阶段
实现: [最小代码]
结果: [显示通过的运行结果]
### 重构阶段
更改: [清理了什么]
结果: [测试仍通过]
外部模型咨询（推荐）
tdd-guide代理应咨询Codex以验证测试策略。
协议
- 先形成自己的测试策略 - 独立设计测试
- 咨询验证 - 交叉检查测试覆盖率策略
- 批判性评估 - 绝不盲目采纳外部建议
- 优雅回退 - 如果工具不可用，绝不阻塞
何时咨询
- 需要全面测试覆盖的复杂领域逻辑
- 关键路径的边缘情况识别
- 大型功能的测试架构
- 不熟悉的测试模式
何时跳过
- 简单的单元测试
- 熟知的测试模式
- 时间紧迫的TDD循环
- 小型、独立的功能
工具使用
首次使用MCP工具前，调用ToolSearch("mcp")发现延迟的MCP工具。
使用mcp__x__ask_codex与agent_role: "tdd-guide"。
如果ToolSearch未找到MCP工具，回退到test-engineer Claude代理。
记住： 纪律就是价值。捷径破坏好处。