tdd

来源

这是中文译文，方便对照阅读。本站不发行中文版插件。英文原文 pstack/skills/tdd/SKILL.md，取自 pstack 官方仓库 cursor/plugins 的提交 12d587d。

本站英文页

TDD Bug Fix

修复有清晰、廉价测试路径的 bug 时，先让错误行为可执行，再改生产代码。目标是聚焦的回归测试：修复前失败，修复后通过。

不要强行写测试。若可用测试需要大量 harness、脆弱 mock、慢端到端基础设施、仅生产状态、模糊复现步骤或大量无关 fixture 改动，则跳过新测试，改用最接近的有效验证。

工作流

1. 理解 bug。 识别预期行为、当前行为、受影响路径与最小可观察复现。
2. 选最窄的可执行检查。 优先该代码路径已有的最近单元、组件、集成或回归测试。若无明显实用测试路径，不要为满足流程从零创建。
3. 先写失败测试。 添加能抓住该 bug 的最小聚焦测试。测试应编码预期行为，而非镜像当前实现。
4. 修复前跑新测试。 确认因预期原因失败。若通过或失败原因不对，先修正测试或复现，再改实现。
5. 修复 bug。 做满足预期行为的最小生产改动，保留附近契约。
6. 重跑回归测试。 确认测试现已通过。

若失败测试不现实

改用最接近的可执行回归检查：定向脚本、手动复现命令、浏览器自动化、快照对比、日志断言或聚焦集成检查。

宁可无新测试也不要坏测试。坏测试指：主要测 mock、编码实现细节、依赖 timing 或无关全局状态、小修复却要昂贵基础设施、或证明修复后立刻会被删。

护栏

• 不要为匹配错误实现而改测试。
• 不要削弱现有断言，除非预期行为确实变了且理由清楚。
• 回归测试聚焦 bug。避免大量 fixture 改动或无关覆盖率扩张。
• 若 bug flaky，尽量让测试确定，并文档化所锁定的信号。
• 若 bug 暴露更广一类失败，先 land 聚焦回归路径，再考虑 sibling 覆盖。

最终回复

报告证据，不只结果：

• 点名修复前失败的测试或可执行检查及其失败表现。
• 点名修复后通过的测试运行及附近验证。
• 若无法展示修复前证据，说明原因并描述所用的最接近回归检查。