tdd

name	tdd
description	测试驱动开发（TDD）。遵循红-绿-重构循环（Red-Green-Refactor）。适用于：用户要求 TDD、提到"单元测试"、"功能测试"、"红绿重构"、"确保功能正常"、"确保测试通过"或要求每次提交都附带测试时触发。

测试驱动开发（TDD）

核心原则

测试验证行为，不验证实现细节。 代码内部可以完全重写，测试不应随之失效。

好的测试通过公共接口描述系统"做什么"，而非"怎么做"。一个好的测试读起来像规格说明——"用户可以用有效购物车完成结账"——明确表达了系统能力。

详见 tests.md 中的好坏测试对比，以及 mocking.md 中的 mock 使用规范。

禁止：横向切片

不要先写完所有测试，再写所有实现。 这是"横向切片"——把 RED 阶段理解为"写所有测试"，GREEN 阶段理解为"写所有代码"。

这会产生劣质测试：

• 批量写出的测试验证的是"想象的行为"，不是"实际行为"
• 测试倾向于验证数据结构和函数签名，而非用户可感知的行为
• 测试对真实变更不敏感——行为破坏时通过，行为正常时失败

正确方式：垂直切片（追踪子弹）。一个测试 → 一个实现 → 循环。

错误（横向）：
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

正确（垂直）：
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3
  ...

工作流

1. 规划

编写任何代码前：

• 与用户确认需要变更哪些接口
• 与用户确认哪些行为需要测试（优先级排序）
• 识别深度模块机会（小接口、深实现）
• 列出待测行为（不是实现步骤）
• 获取用户确认

不可能测试一切。 聚焦在关键路径和复杂逻辑上，不要追求每个边界条件。

2. 最小单元测试原则

每个测试必须：

• 只测试一个行为
• 使用公共接口，不访问内部状态
• 独立运行，不依赖其他测试的状态
• 快速执行，毫秒级完成
• 命名清晰，名称即规格说明

命名模板：[场景/前置条件]_[操作]_[预期结果]

// 好的命名
test("有效购物车_结账_返回已确认状态")
test("空密码_登录_返回验证错误")

// 差的命名
test("测试结账功能")
test("登录测试")

3. 追踪子弹（第一个测试）

写一个测试，验证系统端到端的一件事：

RED:   为第一个行为写测试 → 测试失败
GREEN: 写最少的代码让测试通过 → 测试通过

4. 增量循环

对每个剩余行为：

RED:   写下一个测试 → 失败
GREEN: 最少代码通过 → 通过

规则：

• 每次只写一个测试
• 只写让当前测试通过的代码
• 不预判未来测试
• 测试只关注可观测行为

5. 重构

所有测试通过后，查找重构点（详见 refactoring.md）：

• 提取重复逻辑
• 深化模块（将复杂性隐藏在简单接口后）
• 应用 SOLID 原则
• 运行测试，确保重构后全部通过

绝不在 RED 状态重构。先到 GREEN，再重构。

每轮循环检查清单

[ ] 测试描述行为，不描述实现
[ ] 测试只使用公共接口
[ ] 测试能在内部重构后继续通过
[ ] 实现代码是让测试通过的最少代码
[ ] 没有添加投机性功能

补充参考

• tests.md — 好坏测试示例
• mocking.md — mock 使用规范
• refactoring.md — 重构候选项