先写测试, 再写代码

superpowers 核心技能 · test-driven-development

一句话: 别让 AI 先堆功能再补测试. 让它先写测试, 看着它失败, 再写刚好让测试通过的代码.

场景: 写一个运费计算函数

运费规则一堆边界: 满 99 包邮, 偏远地区(新疆西藏)加收, 按重量阶梯计价, 活动期免运费. 这种"规则多, 边界刁"的函数, 最容易写出"看着对, 一上线就有人投诉运费算错"的代码. 正是 TDD 的主场.

怎么对 AI 说

用 TDD 写运费计算函数: 每条规则先写一个会失败的测试(满99包邮/偏远加收/阶梯重量/活动免运),
跑给我看它失败, 再写最小代码让它通过. 没有先失败的测试, 不许写实现.

抓它一个动作: 让它把"测试失败"那一步的输出贴出来. 一个从没失败过的测试, 可能压根没覆盖那条运费规则.

它会怎么跟你走

它一条规则转一圈: 写"满 99 包邮"的失败测试 -> 跑确认它确实失败(还没实现)-> 写最小代码让它过 -> 再跑确认通过 -> 下一条"偏远地区加收"再来一圈…… 每个边界(98 元 vs 99 元, 新疆 vs 上海)都落成一个测试. 你要是让它先把函数写出来再补测试, 按规矩要删掉重来.

一句话记住

test-driven-development = 让 AI 先写测试看它失败, 再写实现. 像运费这种边界多的逻辑, 一条规则一个测试先行, 上线才不会被"算错钱"打脸.