名称: 测试门 描述: 验证测试覆盖率和鼓励测试习惯。警告门，在/own:done流程中检查测试而不阻塞。
门 6: 测试验证
“测试是理解的证明。如果你不能测试它，你真的理解它吗？”
目的
这个门鼓励初级开发者为他们功能编写测试。与所有权门不同，这不阻止完成 - 它发出警告以鼓励测试习惯。
门状态
- 通过 — 测试存在并覆盖关键路径
- 警告 — 没有测试或覆盖不足（可以继续并记录）
注意： 这个门不阻止。目标是通过鼓励而不是强制来建立测试习惯。
门问题
按顺序提问：
问题 1: 测试存在性
“你为这个功能写了什么测试？”
寻找：
- 至少有一个测试文件存在
- 测试实际上在运行（未跳过）
- 测试有意义（不仅仅是
expect(true).toBe(true)）
如果没有测试：
“我注意到没有这个功能的测试。测试不是完成所必需的，但这是一个值得建立的习惯。如果你有时间，你会测试什么？”
问题 2: 覆盖策略
“你的测试证明了关于这个功能的什么？”
寻找：
- 覆盖了快乐路径
- 考虑了至少一个边缘情况
- 错误状态（如果适用）
后续：
“如果我破坏了[特定部分]，哪个测试会捕捉到它？”
问题 3: 测试质量
“给我看你最重要的测试。它验证了什么行为？”
寻找：
- 测试行为，而不是实现
- 清晰的测试名称
- AAA模式（安排，行动，断言）
响应模板
如果通过（测试存在）
✅ 测试门：通过
很好的工作包括了测试！我看到你覆盖了：
- [他们写的特定测试]
- [他们处理的边缘情况]
关键优势：[他们做得好的地方]
考虑添加：[未来的一个建议]
移至代码审查...
如果警告（没有测试）
⚠️ 测试门：警告
未找到这个功能的测试。没关系 - 我们可以继续。
但这是为什么测试重要：
1. **面试黄金**："我为关键流程实现了测试..."
2. **信心**：知道你的更改不会破坏东西
3. **文档**：测试显示代码应该如何使用
下次的快速胜利：
- 首先测试快乐路径
- 添加一个边缘情况
- 这已经比大多数好了！
继续进行代码审查...
如果警告（弱测试）
⚠️ 测试门：警告
测试存在但可能更强：
**问题**：[缺少或弱的地方]
**问题**："如果[场景]，你的测试会捕捉到它吗？"
这不阻止你，但考虑：
- [具体的改进建议]
继续进行代码审查...
什么构成一个好的测试套件？
| 级别 | 覆盖率 | 特征 |
|---|---|---|
| 最小 | 1-2 测试 | 仅快乐路径 |
| 好 | 3-5 测试 | 快乐路径 + 主要边缘情况 |
| 强 | 5-10 测试 | 快乐路径 + 边缘情况 + 错误状态 |
| 面试就绪 | 全金字塔 | 单元 + 集成 + 端到端关键流程 |
苏格拉底式指导
如果他们想添加测试但不知道从哪里开始：
- “如果什么东西坏了，那会真的很糟糕的一件事是什么？”
- “用户永远不会发送但黑客可能发送的输入是什么？”
- “当服务器慢或返回错误时会发生什么？”
堆栈特定提示
| 堆栈 | 建议 |
|---|---|
| Vite + React | “Vitest + React Testing Library 快速且集成” |
| Next.js | “Vitest 或 Jest 与 Next 工作很好” |
| API/后端 | “用 supertest 或原生 HTTP 测试你的端点” |
| Python | “pytest 是标准 - 简单且强大” |
面试连接
“测试是面试黄金。”
当他们通过这个门有测试时：
- 记录在 STAR 故事中
- “你可以在面试中谈论你的测试策略”
- “你达到了多少覆盖率？”（用于简历）
当他们跳过测试时：
- “下次，即使 2-3 个测试也会对你的作品集有很大不同”
- “雇主喜欢在你的仓库中看到测试文件”
为什么是警告而不是阻止？
- 鼓励 > 强制：通过积极强化建立习惯
- 有些功能是琐碎的：不是所有都需要测试
- 时间约束存在：生产压力是真实的
- 学习曲线：测试有学习曲线；不要阻止进步
目标是让测试感觉有价值，而不是惩罚性。