6.2 自动化测试与 TDD

自动化测试把已知期望变成可重复运行的反馈。它不能替你理解用户，也不能保证产品方向正确，但它能让团队在改动时更快知道“旧承诺有没有被破坏”。

TDD 是一种把测试反馈放到开发之前的工作方式：先写一个会失败的测试，再写最小代码让它通过，然后在测试保护下重构。

自动化适合什么

自动化测试特别适合稳定、明确、可判定的期望：

• 输入输出规则。
• 边界值。
• 权限和错误码。
• API 契约。
• 数据迁移前后兼容性。
• 曾经出现过的回归缺陷。

它不擅长独自回答“用户是否喜欢这个体验”“这个功能是否值得做”“文案是否让真实用户困惑”。这些问题需要用户研究、实验、观察和产品判断。

TDD 的真实收益

TDD 的价值不是“测试覆盖率更好看”，而是把设计压力提前暴露出来。如果一个小行为很难先写测试，可能说明接口太耦合、依赖太难替换、职责边界不清晰。

Red-Green-Refactor 的节奏让团队保持小步：

• Red：测试失败，证明测试能抓住缺口。
• Green：最小实现，避免一次性塞入太多猜测。
• Refactor：在行为保护下整理结构。

TDD 并不适合所有工作。探索性 UI、一次性脚本、未知算法调研，可能需要先做原型。但当规则清晰、回归代价高、接口边界重要时，TDD 能把反馈从“发布后”提前到“写代码时”。

自动化测试也需要维护

坏自动化会制造噪声：不稳定测试、只测实现细节的测试、没有断言的测试、过度模拟真实依赖的测试，都会降低团队对测试的信任。

一个健康测试套件应该：

• 失败原因清楚。
• 运行速度符合它所在层级。
• 测试名称表达行为。
• 不把每个内部重构都变成测试失败。
• 对关键风险有明确断言。

自动化测试不是越多越好，而是越有信号越好。