从「能跑通」到「敢放心」Codex 生成单元测试的真实体验第一次用 Codex 生成单元测试时我的期待其实挺朴素的——把覆盖率数字刷上去少写点重复劳动。但真正跑下来才发现AI 生成的测试代码远不是「一键搞定」那么简单。它更像是一个效率极高的初级工程师主流路径写得飞快细节处却需要你来把关。理想路径覆盖快但不够深Codex 对正常业务流程的覆盖确实省心。以我最近一个订单模块为例输入「为 OrderService 的分页查询方法生成单元测试」后它能在几秒内产出包含参数组装、Mock 依赖、断言返回结构的完整用例。测试框架用的是项目里已有的 JUnit 5 Mockito无需额外调整。但仔细审阅会发现这些用例大多停留在「输入合法参数 → 期望正常返回」的层面。比如分页查询Codex 会测pageNum1, pageSize10的场景却不会主动想到pageSize0时框架的默认行为或者排序字段为空时的降级逻辑。这种「理想路径的完备性」是一种表面完备——代码能跑、覆盖率好看但距离「测得踏实」还有距离。边界与异常AI 的盲区人的责任真正暴露问题的是边界条件和异常场景。Codex 生成的测试里空值校验、越界索引、并发冲突这些高频踩坑点出现频率明显偏低。我做过一个对比实验同一个用户注册模块Codex 自动生成了 12 条用例其中仅 2 条涉及异常分支而人工补充后最终用例数达到 28 条异常和边界场景占比超过一半。典型的遗漏包括参数边界手机号格式正确但带空格、密码长度恰好在边界值状态异常重复提交、并发注册时的唯一键冲突依赖故障短信服务超时、数据库连接池耗尽时的降级表现这些场景不是 Codex 完全写不出而是它需要更精确的提示。如果你只给「写测试」它默认走主流程只有明确告诉它「重点覆盖异常输入和第三方依赖故障」产出才会改善。这也印证了使用 AI 编程工具的一个核心经验需求描述越具体结果越可用。可维护性代码能跑但未必好读Codex 生成的测试代码在语法层面通常干净但可读性和维护性因人而异。常见的问题包括命名模糊测试方法名喜欢用test1()、testOrder()这类缺乏描述性的命名而非shouldThrowExceptionWhenPhoneExists()这种自解释风格Setup 臃肿多个用例共享的 Mock 逻辑没有合理抽取导致每个测试方法前都拖着大段重复代码断言粒度粗习惯用assertNotNull(result)代替对具体字段的精确校验测试失败时定位困难我的做法是把 Codex 的产出当作「草稿」而非「终稿」。生成后统一走一遍重构提取公共的 Mock 构建器、把魔法数字换成常量、用更语义化的断言库如 AssertJ 替换基础断言。这个过程通常花费原时长的 30% 左右但换来的是后续维护时少踩很多坑。与现有框架的兼容 surprisingly 顺滑值得肯定的是框架兼容度。Codex 能识别项目已有的技术栈并自动适配——Spring Boot 项目自动引入SpringBootTest用了 MyBatis-Plus 的会自动注入对应的 Mapper Mock。我试过在既有 Spock 测试Groovy和 JUnit 混合的项目里使用它也能根据上下文选择对应方言没有生搬硬套。一个小技巧是提前在项目的AGENTS.md或类似配置里写明测试规范比如「所有 Service 层测试必须 Mock 外部 HTTP 调用」「数据库测试使用DataJpaTest而非完整上下文」。Codex 会读取这些约束减少后续调整成本。人工补充的典型方向经过几轮实践我总结了一套「AI 生成 人工补强」的协作模式。Codex 负责快速搭建骨架和主流程以下方向则必须人工介入补充方向具体做法示例异常分支枚举所有可预见的错误码和异常类型参数校验失败抛BizException系统异常抛RuntimeException并发场景用CountDownLatch或CompletableFuture模拟多线程库存扣减时的并发一致性依赖行为验证用verify()确认关键副作用发生确认注册成功后确实发送了短信数据构造多样性覆盖空集合、单元素、超大集合等分页查询返回空列表时的处理合理预期工具而非替代Codex 生成单元测试的真正价值不在于取代测试工程师的思考而在于把重复性的样板代码压缩到最低。我的实际体验是它能帮我节省 40%-60% 的机械编码时间但剩下的 40% 恰恰是区分测试质量高低的关键。自动化测试的合理预期应该是「AI 写得出我能写的但写不出我能想到的」。覆盖率数字可以靠工具快速拉升但测试的有效性——能否在重构时保驾护航、能否在故障前提前预警——仍然依赖人对业务理解和对风险的预判。现在我的习惯是每次 Codex 生成测试后先跑一遍 Mutation Testing变异测试看看这些用例到底能不能拦住故意引入的代码缺陷。这个环节里AI 生成的测试往往会有 20%-30% 的漏网之鱼而这些正是人工需要补上的地方。把 Codex 当作一个高效的结对编程伙伴而不是甩手掌柜或许才是当下最务实的用法。