用AI写单元测试：我把覆盖率从40%提到了85%

我们项目有一个历史遗留问题：核心支付模块的单元测试覆盖率只有40%，新需求上线全靠手工回归，测试同事每次发版都提心吊胆。上个月我试了用AI批量生成单元测试，一个月下来覆盖率提到了85%，测试同事反馈"比人写的还规矩"。这篇文章记录一下我的完整做法和踩过的坑。

一、为什么之前补测试这么难

覆盖率低的根本原因不是"不想写"，而是"写不动"：

1. 存量代码看不懂：三年前的老模块，没有注释，方法逻辑绕，手写测试要先把业务读明白；
2. 测试样板代码多：mock、初始化、断言，一个用例一半是模板代码，纯体力活；
3. 边界条件想不到：人写测试容易顺着"正常路径"走，异常路径、边界值经常漏掉；
4. 没时间：业务排期紧，测试永远排在最后。

二、我的AI补测流程

第1步：让AI先"读懂"再"出题"

我把要补测的类和方法贴给AI，让它先输出一份"方法说明"：每个方法的输入、输出、依赖、边界条件、可能抛出的异常。这一步很关键——先让AI解释一遍，它后续生成的测试才有针对性，而不是瞎猜。

第2步：按"行为"生成用例

提示词的大致思路是：

为以下方法生成JUnit单元测试：覆盖正常路径、异常路径、边界值（空值、极值、非法参数）、依赖失败（mock抛异常）四类场景；使用Mockito mock所有外部依赖；每个测试给出简短的场景注释。

AI生成的测试有个明显优点：边界条件比人想得全。比如金额计算方法的0.00、负数、超大数、精度边界，它全都覆盖了，这正好补上了我们最弱的一环。

第3步：人工只做"三道关卡"

AI生成的测试我不会直接合入，而是过三道检查：

1. 逻辑正确性：AI偶尔会把业务规则理解偏——比如把"满减"算成"直接减"，这类测试合入等于把错误固化下来，必须人眼看；
2. 真伪判断：跑一遍，确认测试是"真失败"的（能抓bug），而不是"假通过"（断言写得太松）；
3. 覆盖率验证：用JaCoCo看增量，确认每个方法的分支都被覆盖到了。

三、踩坑记录

1. "测试污染"问题：AI生成的测试偶尔会修改共享静态状态（比如全局配置类），导致测试互相影响、随机失败。我的对策是要求AI"所有依赖必须显式注入或mock，禁止修改静态状态"，并在CI里跑三次验证稳定性；
2. mock过度：一开始AI把什么都mock了，测出来的东西和真实行为脱节。后来我要求"业务纯函数尽量用真实实现，只mock IO类依赖"；
3. 一次性喂太多：把整个类几十个方法一次性丢给AI，输出质量明显下降且容易截断。改成"一次一个方法，最多三个"后，质量稳定了；
4. 别让AI生成"刷覆盖率的测试"：AI有时会生成只断言"不抛异常"的空测试来充数，这种测试没有价值。我的验收标准是：每个测试必须有具体的输入-输出断言。

四、效果与总结

一个月的数据：核心模块覆盖率从40%升到85%，新生成的测试数量约600个，其中人工修改率约20%（主要是业务规则理解偏差和边界修正）。最有说服力的是：上线前测试同事用变异测试工具跑了一遍，我们补的测试"杀掉"了87%的变异体，说明这些测试是真的能抓bug，不是充数的。

我的心得是：AI写测试的定位是"高效的生产力工具"，不是"免检的测试工程师"。它把最耗时的手工劳动（读代码、写样板、想边界）自动化了，但业务规则的正确性、测试的有效性，必须由人把关。如果你也在为存量代码的覆盖率头疼，强烈建议用AI从"老模块+高价值方法"开始补，收益立竿见影。