用 AI 写单元测试：让它产出能跑、能信的测试

单元测试这件事，老司机知道重要，新手总觉得"能跑就行，测什么测"。真到线上出 bug、回头补测试的时候，又发现一堆测试要么跑不通、要么写的是样子货。AI 编码助手把写测试的成本压到了很低，但"它写得出"和"你信得过"是两回事。

下面是我实际用下来，让 AI 产出能跑、能信的单元测试的一套做法。

先把"被测对象"喂清楚

AI 写测试最容易翻车的地方，是它只看到了函数签名，没看到函数的真实契约。你直接说"给这个函数写测试"，它往往凭猜测补参数，测出来的用例和你的业务边界对不上。

更好的喂法是三件套：

契约说清楚了，AI 才知道该测"它该拒绝什么"，而不只是"它算对了吗"。

别一上来就让 AI 吐完整测试文件。先让它列出"你会覆盖哪些用例"，你过一眼，把明显遗漏的边界补上，再让它落地代码。这一步能挡掉一大半"测试看着多、其实没测到点"的情况。

我习惯要求它把用例分成三组：正常路径、边界路径、异常路径。异常路径最容易被省掉，但线上炸的往往就是这里。

AI 写的测试，第一版能直接通过的我遇到的大概一半一半。剩下的一半里，常见问题是 import 路径不对、测试框架版本不一致、mock 写错对象。所以规定动作是：让它写完后当场跑，把报错贴回去让它改，直到全绿。

千万别"看着差不多就提交"。没跑过的测试进了仓库，比没有测试还糟，因为它会给你虚假的安全感。

第一，mock 过度。 AI 喜欢把依赖全都 mock 掉，结果测的是"mock 有没有被调用"，而不是"逻辑对不对"。能不 mock 就用真实依赖或轻量替身，只 mock 真正不可控的外部服务。

第二，测实现不测行为。 比如它断言"第几行调用了某个内部方法"，函数一重构测试就全挂。好的测试只关心输入输出，不关心内部怎么走的。

第三，制造了 flaky 测试。 依赖当前时间、随机值、并发时序的测试，本地绿了 CI 红。让它把这类不确定性固定下来（注入时间、固定种子、用确定性数据）。

AI 适合补那些"我知道要测什么、但写起来烦"的样例：解析器、工具函数、数据转换。但涉及安全边界、金额计算、并发正确性这种"测错了代价很大"的地方，我建议自己定用例、自己审断言，只把机械的书写交给 AI。

一句话：AI 负责把测试写得快，你负责决定测什么、信不信。分工清楚了，测试才真正替你兜底。