完成前验证
为什么有前端的项目必须 E2E 测试
注意：此要求仅适用于有前端的项目。纯后端项目跳过 E2E 测试。
- •单元测试和组件测试无法发现运行时问题
- •代码看起来对，但实际跑起来可能有 bug
- •必须在真实浏览器环境中验证
- •这是确保代码可用的最后一道防线
概述
不验证就声称工作完成是不诚实，而非效率。
核心原则： 始终证据先于声明。
违反此规则的文字就是违反此规则的精神。
铁律
code
没有新鲜验证证据，不得声称完成
如果在本消息中没有运行验证命令，就不能声称它通过。
门控函数
code
在声称任何状态或表达满意之前： 1. 识别：什么命令证明此声明？ 2. 运行：执行完整命令（新鲜、完整） 3. 阅读：完整输出，检查退出代码，统计失败 4. 验证：输出是否确认声明？ - 如果否：用证据陈述实际状态 - 如果是：用证据陈述声明 5. 只有这样：做出声明 跳过任何步骤 = 撒谎，而非验证
常见失败
| 声明 | 需要 | 不足够 |
|---|---|---|
| 测试通过 | 测试命令输出：0 失败 | 之前的运行，"应该通过" |
| 检查器干净 | 检查器输出：0 错误 | 部分检查，推断 |
| 构建成功 | 构建命令：exit 0 | 检查器通过，日志看起来不错 |
| Bug 已修复 | 测试原始症状：通过 | 代码更改，假设已修复 |
| 回归测试有效 | 红绿循环已验证 | 测试通过一次 |
| 代码质量 | lint 输出干净 | 代码看起来不错 |
验证检查清单
必须验证
- • 所有测试通过 (
npm test或pytest) - • Lint 检查通过 (
npm run lint或ruff check) - • 类型检查通过 (
npm run type-check或mypy) - • 构建成功 (
npm run build) - • 无引入新问题
前端额外检查
- • 组件测试通过
- • E2E 测试通过（有前端则必须）
- • 无控制台错误
E2E 测试检查清单
仅适用于有前端的项目
- • 关键用户流程已覆盖 E2E 测试
- • 测试在无头模式（headless）下通过
- • 测试使用稳定的选择器（data-testid）
- • 失败时自动截图
- • 关键断言已添加
- • 超时配置合理（单个测试 ≤30s，断言 ≤5s）
- • 无长时间等待（无 waitForTimeout 硬编码）
后端额外检查
- • API 测试通过
- • 数据库迁移正常
- • 无敏感数据泄露
危险信号 - 停止
- •使用"应该"、"可能"、"似乎"
- •验证前表达满意（"太好了！"、"完美！"、"完成了！"等）
- •未验证就提交/推送/PR
- •信任代理成功报告
- •依赖部分验证
- •想"就这一次"
- •累了想结束工作
验证流程
code
1. 运行测试 ↓ 2. 检查输出 ↓ 3. 记录结果 ↓ 4. 做出声明
正确示例
❌ 错误：
"测试通过了，可以合并了"
✅ 正确：
"运行
npm test，输出显示 15 passed, 0 failed。测试通过，可以合并。"
❌ 错误：
"Bug 已修复"
✅ 正确：
"运行原始复现步骤 now returns expected result。Bug 已修复。"
当验证失败时
- •不要声称成功
- •报告实际输出
- •分析失败原因
- •修复问题
- •重新验证