AI 写测试比修 Bug 更耗时
我坚持认为，AI 生成测试用例的调试成本，远高于它帮你节省的手写时间。理由有二：一是它总爱捏造不存在的断言和 Mock 对象，跑起来全是红海；二是业务逻辑一变，生成的测试几乎要推倒重来，比修业务 Bug 还让人头疼。既然大家都在鼓吹 AI 提效，那在测试覆盖率这个硬指标上，它到底是真帮手还是新负担？
Replies (4)
Log in to join the discussion.
我坚持认为，AI 生成测试用例的调试成本，远高于它帮你节省的手写时间。理由有二：一是它总爱捏造不存在的断言和 Mock 对象，跑起来全是红海；二是业务逻辑一变，生成的测试几乎要推倒重来，比修业务 Bug 还让人头疼。既然大家都在鼓吹 AI 提效，那在测试覆盖率这个硬指标上，它到底是真帮手还是新负担？
Log in to join the discussion.
说实话我站你这边。上个月我用 Cursor 给一个支付模块补单测，生成的 Mock 花里胡哨的，结果底层 SDK 版本一换，三十多个断言全废了，修到凌晨两点，比我自己手撕还慢。我现在学乖了，AI 只用来生成数据实体和构造器，核心断言必须自己撸，别把它当主力，当个会打字的新人实习生用就行。
太真实了，我现在也是这感觉。AI写测试就像个自信满满的实习生，代码能跑通但它自己都不知道在测啥，尤其重构的时候，改业务代码五分钟，修它的断言两小时。后来我学了一招，把AI当成“测试数据工厂”，让它专门造各种边界条件的入参和预期结果集，断言结构自己搭骨架，这样既省了敲样板代码的功夫，又不用给AI擦屁股擦到怀疑人生。
作为经常拿不同模型跑同一套测试集的人，我觉得这事儿得看模型。Claude 3.5 Sonnet 写单元测试的通过率确实能到七八成，但 DeepSeek 和 Gemini 在某些框架下就是大型翻车现场，Mock 对象能给你捏到包名都对不上。所以我的结论是，AI 写测试不是不能提效，但你得先摸清手里这个模型的“脾气”，别一上来就全量跑，先拿一个复杂模块试水，测准它的翻车规律再决定用不用。至于业务变更推倒重来这事，说实话手写也一样要重来，只是你更愿意花时间骂自己还是骂AI的区别罢了。
楼上几位说得都在理，但我感觉关键还是看项目阶段。新项目从零开始，AI 生成那一堆基础 CRUD 的测试确实香，省了我大把敲样板代码的功夫；可但凡进到维护期，业务逻辑跟意大利面条似的，AI 一测一个坑，修它生成的 Mock 比改老代码还痛苦。我现在策略很简单，新功能就用 AI 跑个基础覆盖，老模块改动全凭手撸，别跟自己的睡眠时间过不去。