keep-it-working

保持功能可用

目标不是写测试，而是确保今天刚做好的功能在演示日依然可用，即使之后又经历了 40 次改动，还由一个不知道哪些内容不能碰的 Agent 来操作。

所以，每实现一个功能后要问的从来不是“要不要写测试”，而是**如果它坏了，我们会发现吗？如果没发现，后果有多严重？**回答这两个问题，就能选出合适的级别。

测试阶梯

选择能真正捕获故障的最低成本级别。超出风险所需、盲目往上加码，就会把两周的冲刺变成测试项目。

级别	适用场景	操作方式
1. 看一眼	故障一眼就能看出来——布局、文案、颜色、间距	打开页面，看一眼。完成。这里不值得写测试
2. 走一遍流程	多步骤流程，但仍能手动点击走通——注册 → 创建 → 查看列表	在运行中的应用里从头到尾走一遍，并报告观察结果。无需设置，也无需文件。参见 playwright
3. 写一个测试	故障发生时不易察觉，或手动检查需要超过一分钟——后台任务、webhook，以及任何涉及数据库往返的操作	为正常流程写一个测试。不是整套测试。对于完整流程，使用 playwright
4. 先写测试	代码尚不存在时就能明确说出规则，或者正在修复一个可复现的 bug	先写一个会失败的测试，观察它失败，然后让它通过

先写测试何时真正值得

这不是原则问题，而是计算问题。在以下情况下先写测试：

• 能用一句话说明输入、输出和规则。“订单金额超过 ₹2000 时免运费，国际订单除外。”定价、评分、配额、限制、权限、日期计算都属于这类。这个句子本身就是测试，因此先写测试几乎不费成本，还能在代码偏离之前把规则固定下来。
• **bug 可复现。**始终如此。能触发的 bug，只需一分钟就能写成测试；这也是确认修复确实有效并能持续有效的唯一方法。这是任何冲刺项目中价值最高的测试。
• **存在多个分支。**空、一个、多个、过多、类型错误、已过期、已使用。如果你原本要通过点击检查五种情况，那么第二次运行时，用代码检查会更快。
• **会反复修改。**任何已经重写过一次的东西，都可能再次被重写。

以下情况不要先写测试：

• **这是视觉效果。**测试看不见。使用级别 1 或 2。
• **还不知道什么才算正确。**先探索并让功能跑起来，然后再判断是否值得用测试固定下来。先探索没问题——但别把探索留在那里就算完成。
• 这是一次性任务——只运行一次的迁移脚本、用于填充假数据的脚本，或已商定要丢弃的原型。

不容商量的规则

**任何曾经出过问题的东西，都要加上测试。**无需判断，也不必看测试阶梯。它坏过，就可能再次坏掉，而且现在你已经知道如何触发它。

这样才能避免冲刺中最糟糕的情况：周二修好的东西，Agent 在周四悄悄又弄坏了，直到演示时才有人发现。

别在值得之前就搭建测试环境

冲刺技术栈没有自带测试运行器，而且这是正确的——大部分工作都属于级别 1 和 2。

第一次真正需要级别 3 或 4 时，安装最精简的测试运行器，并写下那一个测试。不要加配置，不要建整套测试，也不要做覆盖率检查。如果设置要花掉他们冲刺中的几分钟以上，就说明这一点并提供级别 2 作为替代方案，然后让他们选择。

测试就绪后

• 每次更改后都运行测试，而不只是运行与本次更改相关的测试。
• 测试套件未通过？停下来。先修好，再添加新内容。在测试未通过的情况下继续构建，整个下午就会这样耗掉。
• 按名称报告每一项失败，包括不是由你导致的失败。测试未通过，却悄悄滚过而未被提及，这是有意隐瞒。
• 保持测试可信：名称要说明行为，断言要针对真实行为，而不是模拟对象，每个测试只验证一种行为。一个永远不会失败的测试比没有测试更糟，因为它会带来虚假的信心。

如何沟通

绝不要说“你本该写测试”。他们正在学习如何交付，而这套阶梯的存在就是为了让他们不必背负那种愧疚。

指出值得保护的内容和所需成本：“定价规则这类东西很容易悄悄出错——花两分钟把它锁定，要我来吗？” 然后尊重对方的回答。如果他们说不，就记下来，继续往下做；无论如何，他们仍有 checkpoint 兜底。

当测试捕获到回归问题时，要明确说出来。这一刻，这个想法本身就足以说明一切。

---

我们的做法。红绿开发规范和测试诚信规则改编自 obra/superpowers，采用 MIT License；阶梯，以及“何时值得投入”的判断，是我们自己的，因为冲刺中的构建者应先交付，再证明。