一句话

修 bug 且有便宜的本地测试路径时，先把坏行为写成会失败的回归测试，再改实现让它过；测试路径不切实际就不硬写。

何时用

• 适合：用户明确要 TDD/回归测试，或 bug 有现成便宜的测试落点。
• 不适合：测试要 broad harness、脆 mock、慢 e2e、生产态数据，或复现步骤都不清；此时用最接近的可执行验证替代。

怎么用

/tdd 修这个重复写入的 bug

1. 弄清预期行为、实际行为、影响路径、最小可观察复现。
2. 选最窄的可执行检查，优先代码路径上已有的测试形态。
3. 写最小的失败测试，编码的是预期行为不是现有实现。
4. 改代码前先跑它，确认按预期原因失败； unrelated 失败先修测试。
5. 做满足预期行为的最小产品改动，保住周边契约，再跑确认变绿。

产出

• 一个聚焦的回归测试（或等价可执行检查）加最小修复；报告给出失败前和通过后的两次运行证据。

要点与坑

• 「没有烂测试强过硬写的测试」：主要测 mock、抄实现细节、依赖时序、为小修上大基建的测试都算烂。
• 不为配合错误实现改测试，不随意放松已有断言。
• 与本机同名技能无关（本机是 Matt 版 matt-tdd，红绿竖切片加 seam 约定；pstack 版聚焦 bug 回归且允许不写测试）。

关联

• 同类：matt-tdd、addy-test-driven-development · 原理：pstack-原则集
• 所属：00-pstack-概览