tdd

TDD

用先失败、再通过、后重构的循环驱动实现：每次行为变更都从一个先失败的测试开始，小步推进。

循环

1. 写失败的测试

写一个断言目标行为的测试，只覆盖下一个要做的行为。跑它，看到失败，记下命令与报错输出。没观察过失败就不写实现：失败证明这个测试真能逮住缺失的行为，而不是碰巧通过或根本没有执行。

2. 写最小的通过实现

用最少的代码让测试通过，丑一点没关系，不多写：超出测试断言的实现没有安全网。跑测试，确认成功。

3. 测试全部通过时重构

只在测试全部通过时重构：消除重复、改名、搬代码。小步改，每步重跑测试保持通过。一旦失败，先恢复通过再继续。

何时测试先行，何时后补

代码类型	做法
行为丰富的逻辑（解析、计算、状态机、业务规则）	测试先行，走上面的循环
探索性代码（spike、UI 打磨、胶水配置）	先实现。要保留或要改动时，先写一套把当前实际行为原样断言下来的测试，锁住已有行为

这套锁行为的测试先对当前行为跑一遍并确认全部通过，再开始改动。此后它就是这个行为的回归测试。

测试设计

• 断言可观察行为（返回值、状态变化、对依赖发出的调用），不断言实现细节（内部数据结构、私有方法、调用次序）：断言实现细节的测试会在重构时误报失败。
• 一个测试一个主题。测试名描述行为（“空输入返回 400”），不描述被测方法名。
• 每个行为覆盖正常路径、边界值、错误路径，各是循环里一次独立的失败。

难测试代码

依赖通过接口注入（构造参数、接口字段），让测试能换成可控实现。不硬改生产代码迎合测试框架。

测试替身（stub / fake / spy）只替进程外依赖（网络、数据库、文件系统、时钟）。进程内逻辑用真实实现跑。替身过多时，测试只证明“替身按你写的返回”。

修 bug：先走 diagnosing-bugs

修 bug 时由 diagnosing-bugs 接管，其阶段 5（先于修复写回归测试）就是本 skill 的失败阶段：把缩小后的复现转成失败测试，看到报错，再上修复让它通过。之后要改结构，继续按重构的纪律执行。

完成条件

• 失败被观察过：能说出测试命令与报错输出
• 实现让测试通过
• 重构后测试仍通过
• 新行为全部有测试覆盖，含边界与错误路径