tdd

测试驱动开发

理念

核心原则：测试通过公共接口验证行为，而不是实现细节。代码可以彻底改变；测试不应改变。

好的测试采用集成测试风格：通过公共 API 覆盖真实代码路径。它们描述系统_做什么_，而不是_如何做_。好的测试读起来就像一份规范。由于不依赖内部结构，这类测试经得起重构。

糟糕的测试与实现紧密耦合。它们会模拟内部协作者、测试私有方法，或通过外部手段验证行为。一个警示信号是：重构时测试失败，但行为并未改变。

示例见 reference/tests.md，模拟指南见 reference/mocking.md。

与框架无关

此技能适用于任何测试框架（Vitest、Jest、Playwright、Cypress、pytest、JUnit 等）和任何技术栈（Vue.js、React、Node.js、后端服务）。请根据项目使用的语言和框架调整示例。

反模式：水平切片

不要先编写所有测试，再编写所有实现。 这就是“水平切片”——把 RED 阶段当成“编写所有测试”，把 GREEN 阶段当成“编写所有代码”。

这会产生糟糕的测试：它们测试_想象中的_行为，测试事物的_形态_而非面向用户的行为，并且对真实变化变得不敏感。

正确做法：通过示踪弹丸进行垂直切片。一次编写一个测试、实现一个功能，然后重复。

WRONG (horizontal):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

RIGHT (vertical):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3

工作流

1. 规划

编写任何代码之前：

• 与用户确认需要哪些接口变更
• 确认要测试哪些行为（按优先级排序——不可能测试所有内容）
• 找出适合采用深模块的机会（小接口、深实现）
• 设计便于测试的接口
• 列出要测试的行为（而非实现步骤）
• 请用户批准计划

询问：“公共接口应该是什么样？哪些行为最值得优先测试？”

2. 示踪弹丸

编写一个测试，只验证一件事——证明整条路径端到端可用：

RED:   Write test for first behavior → test fails
GREEN: Write minimal code to pass → test passes

3. 增量循环

对于每个剩余行为：一次只编写一个测试，执行 RED → GREEN。

• 只编写足以通过当前测试的代码
• 不要预想未来的测试
• 让测试专注于可观察到的行为

4. 重构

所有测试通过后，寻找重构候选项：

• 提取重复代码
• 深化模块（将复杂性移至简单接口之后）
• 自然适用时采用 SOLID 原则
• 思考新代码揭示了现有代码的哪些问题
• 每完成一个重构步骤后运行测试

切勿在 RED 阶段重构。 先达到 GREEN。

每个循环的检查清单

[ ] Test describes behavior, not implementation
[ ] Test uses public interface only
[ ] Test would survive an internal refactor
[ ] Code is minimal for this test
[ ] No speculative features added