当 AI 生成的测试通过却漏掉 bug：对 tautological unit tests 的事后分析

Source: Dev.to

Overview

我开始依赖一个助手为一个中等规模的服务搭建单元测试：生成测试用例、模拟依赖并断言输出。乍一看，这加快了审查周期——测试套件迅速增长，CI 显示构建通过。问题只有在一次生产事故后才显现出来，当时一个覆盖率很高的接口返回了悄然错误的数据。

深入分析后发现，生成的测试没有捕捉到 bug，因为它们本质上是复制了实现的假设，而不是对这些假设进行挑战。助手根据它看到的代码模式化测试，产生的断言与内部转换相映射。这种同义反复让套件看起来很全面，实际上却对真实的失败模式视而不见。

关于工具方法的背景阅读，我在主站 crompt.ai 上参考了一个助手，以比较工作流。

How the failure surfaced during development

问题在一次重构后出现日志显示用户可见字段与持久化模型不匹配时被发现。开发者在本地和 CI 中运行测试套件：所有测试都通过。出错的接口拥有单元测试，这些测试模拟了序列化层，然后在测试内部调用相同的序列化实现，并与预先计算的值进行相等断言。由于测试和代码使用了相同的逻辑路径，测试从未触发重构引入的分歧。

我们意识到助手有偏向：它倾向于生成遵循显而易见模式的最小化脚手架，因此只生成了 happy path（正常路径）的测试。它还生成了返回实现所期望的精确结构的 mock。这种行为使得测试对真实输入脆弱，但在模型产生的合成输入下却表现稳定。

Why the problem was subtle and easy to miss

• 绿色测试是强烈的心理信号。 团队会假设 CI 通过等同于正确，尤其是当覆盖率数字看起来健康时。
• 助手的测试提升了覆盖率指标，因为它们触及了代码路径，却没有引入对抗性输入或无效状态。
• 命名和结构的一致性 让生成的测试融入套件，审阅者往往凭表面接受它们。

Model‑side contributors

• 模型倾向于复制训练数据中最常见、最简单的模式，并偏好确定性的单案例示例。
• 除非被明确提示，否则它不会主动提出更具侵入性的测试策略，如基于属性的测试或模糊测试。

这些小选择——默认走 happy path、添加直接的 mock、回避边缘情况——在大量生成的测试中累积后会产生巨大影响。

Mitigations and practical lessons

• 审查清单更新 – 将生成的测试视为草稿产物。审阅者现在会问：这些测试做了哪些假设？以及我们能否用独立或基于 oracle 的检查来替代镜像逻辑？
• 加入基于属性的黑盒集成测试 – 用随机化输入验证行为，而不是固定示例。
• 与助手进行迭代调试 – 使用聚焦的聊天会话来挖掘缺失的边缘情况并生成反例。
• 对照正式规范 – 使用契约测试和轻量级验证步骤，有时会借助专门的深度查询从文档中收集角落案例。

关键要点： 将 AI 生成的测试视为加速器，而非保证。它们能加快草稿编写，但仍需独立验证才能真正防止回归。