ai-regression-testing

原文涵盖的主题

• AI 回归测试
• 何时激活
• 核心问题
• 沙盒模式 API 测试
• 设置（Vitest + Next.js App Router）
• Next.js API 路由的测试辅助工具
• 编写回归测试
• 测试沙盒/生产环境一致性

专为 AI 辅助开发设计的测试模式，其中同一模型编写代码并审查代码——这会形成系统性的盲点，只有自动化测试才能发现。 AI 代理（Claude Code、Cursor、Codex）已修改 API 路由或后端逻辑 发现并修复了一个 bug——需要防止重新引入 项目具有沙盒/模拟模式，可用于无需数据库的测试 在代码更改后运行 /bug-check 或类似的审查命令 存在多个代码路径（沙盒与生产环境、功能开关等） 当 AI 编写代码然后审查其自身工作时，它会将相同的假设带入这两个步骤。这会形成一个可预测的失败模式： 实际示例（在生产环境中观察到）： 模式：沙盒/生产环境路径不一致是 AI 引入的 #1 回归问题。 大多数具有 AI 友好架构的项目都有一个沙盒/模拟模式。这是实现快速、无需数据库的 API 测试的关键。 关键原则：为已发现的 bug 编写测试，而不是为正常工作的代码编写测试。 最常见的 AI 回归问题：修复了生产环境路径但忘记了沙盒路径（或反之）。 频率：最常见（在 4 个回归问题中观察到 3 个） 用于捕获它的测试： 频率：在使用 Supabase/Prisma 添加新列时常见 频率：中等——当向现有组件添加错误处理时 不要追求 100% 的覆盖率。相反： 为什么这在 AI 开发中有效： 1. AI 倾向于重复犯同一类错误 2. Bug 集中在复杂区域（身份验证、多路径逻辑、状态管理） 3. 一旦经过测试，该特定回归问题就不会再次发生 4. 测试数量随着 Bug 修复而有机增长——没有浪费精力 | AI 回归模式 | 测试策略 | 优先级 | |---|---|---| | 沙盒/生产环境不匹配 | 断言沙盒模式下响应结构相同 | 高 | | SELECT 子句遗漏 | 断言响应中包含所有必需字段 | 高 | | 错误状态泄漏 | 断言出错时状态已清理 | 中 | | 缺少回滚 | 断言 API 失败时状态已恢复 | 中 | | 类型转换掩盖 null | 断言字段不为 undefined | 中 | 要： 发现 bug 后立即编写测试（如果可能，在修复之前） 测试 API 响应结构，而不是实现细节 将运行测试作为每次 bug 检查的第一步 保持测试快速（在沙盒模式下总计 < 1 秒） 以测试所预防的 bug 来命名测试（例如，"BUG-R1 regression"） 不要： 为从未出现过 bug 的代码编写测试 相信 AI 自我审查可以作为自动化测试的替代品 因为“只是模拟数据”而跳过沙盒路径测试 在单元测试足够时编写集成测试 追求覆盖率百分比——追求回归预防