测试驱动开发
哲学
核心原则：测试应通过公共接口验证行为，而非实现细节。代码可以完全改变；测试不应改变。
好的测试是集成风格的：它们通过公共API执行真实代码路径。它们描述系统做什么，而非如何做。一个好的测试读起来像一份规范——“用户可以使用有效购物车结账”准确地告诉你存在什么能力。这些测试在重构中存活，因为它们不关心内部结构。
坏的测试与实现耦合。它们模拟内部协作者、测试私有方法，或通过外部手段验证（例如直接查询数据库而不是使用接口）。警告信号：重构时测试中断，但行为未改变。如果你重命名了一个内部函数而测试失败，那些测试是在测试实现，而非行为。
参见 tests.md 获取示例，以及 mocking.md 获取模拟指导。
反模式：水平切片
不要先写所有测试，再写所有实现。 这是“水平切片”——将 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. 规划
在探索代码库时，使用项目的领域词汇表，以便测试名称和接口词汇与项目的语言匹配，并尊重你正在接触的区域的 ADR。
在编写任何代码之前：
问：“公共接口应该是什么样的？哪些行为最重要需要测试？”
你无法测试所有东西。 与用户确认哪些行为最值得关注。将测试工作集中在关键路径和复杂逻辑上，而不是每一个可能的边界情况。
2. 追踪子弹
编写一个测试，确认系统的一件事情：
RED: 为第一个行为编写测试 → 测试失败
GREEN: 编写最简代码以通过 → 测试通过
这是你的追踪子弹——证明路径端到端有效。
3. 增量循环
对于剩余每个行为：
RED: 编写下一个测试 → 失败
GREEN: 最简代码以通过 → 通过
规则：
- 一次只处理一个测试
- 只够通过当前测试的代码
- 不要预期未来的测试
- 保持测试聚焦于可观察的行为
4. 重构
所有测试通过后，寻找重构候选：
- 提取重复
- 加深模块（将复杂性移到简单接口后面）
- 在自然的地方应用 SOLID 原则
- 考虑新代码揭示了现有代码什么
- 每次重构步骤后运行测试
在 RED 状态下永远不要重构。 先到 GREEN。
每次循环检查清单
[ ] 测试描述行为，而非实现
[ ] 测试仅使用公共接口
[ ] 测试能在内部重构中存活
[ ] 代码对该测试是最简的
[ ] 没有添加投机功能