test-driven-development

name	test-driven-development
description	严格的红绿重构循环。铁律：没有失败测试就没有生产代码。在写实现之前先写测试，让测试驱动设计。触发短语："TDD"、"测试驱动"、"写测试"。
allowed-tools	Read, Write, Edit, Glob, Grep, Bash

/test-driven-development — 测试驱动开发

严格遵循红绿重构循环：先写一个失败的测试，再写最少的代码让测试通过，最后重构。

铁律

没有失败测试就没有生产代码。

如果你发现自己在没有先写失败测试的情况下编写了生产代码，立即停下来，删除那些代码，回到测试。

红绿重构循环

RED：写一个失败的测试

1. 从需求中提取一个具体的行为
2. 写一个测试来验证这个行为
3. 运行测试，确认它失败
4. 失败原因必须是"预期行为未实现"，不是语法错误或配置问题

# 运行测试，确认失败
npm test -- --testPathPattern="target-test"
pytest target_test.py -v
./gradlew test --tests "TargetTest"

GREEN：写最少的代码让测试通过

1. 只写让当前失败测试通过的代码
2. 不写额外的功能、不做"顺便"的优化
3. 代码可以很丑，没关系，下一步会重构
4. 运行测试，确认通过

REFACTOR：清理代码

1. 测试通过后，审视实现代码和测试代码
2. 消除重复、改善命名、简化逻辑
3. 每次重构后运行测试，确认仍然通过
4. 重构不改变行为，只改善结构

测试编写原则

测试应该

• 测试行为，不测试实现细节
• 独立运行，不依赖其他测试的执行顺序
• 快速执行，一个测试在毫秒级完成
• 失败时给出清晰的诊断信息

测试不应该

• Mock 自己写的代码（只 mock 外部依赖）
• 测试私有方法
• 包含条件逻辑（if/else）
• 依赖网络、文件系统、数据库的真实状态（除非是集成测试）

详细的反模式说明见 references/testing-anti-patterns.md。

流程

1. 与用户确认要实现的功能或修复的 bug
2. 列出需要覆盖的测试场景（正常路径 + 边界条件 + 错误路径）
3. 按优先级排序，从最简单的场景开始
4. 对每个场景执行红绿重构循环
5. 每 3 到 5 个循环后，回顾整体设计，考虑是否需要更大的重构

与 plan.md 的配合

如果存在 plan.md，每个任务的执行都应该遵循 TDD 循环：

1. 为任务描述的行为写测试
2. 让测试通过
3. 重构
4. 在 plan.md 中标记 [x]