Quality TDD

把测试先行从“建议”变成硬约束。这个 skill 适用于任何会改变行为的 coding 工作。

何时使用

• 开始实现新功能前
• 修 bug 前
• 重构且行为不能变时
• 用户明确触发 /tdd

不适用：

• 一次性原型，且用户明确同意不做长期维护
• 纯配置改动或纯文案改动，没有行为变化

产物

每次使用本 skill，默认产出以下最小集合：

1. 失败测试记录
   • 哪个测试先失败
   • 失败是否符合预期
2. 最小实现记录
   • 哪段实现是为让当前测试通过而新增
3. 质量记录
   • 若当前任务已有自己的记录文件，回写 TDD 阶段摘要
   • 若没有既定记录位置，默认写入 .quality/quality-check.md

工作流

1. 先写一个失败测试
   • 一次只锁定一个行为
   • 测试名要能说明行为，不要写模糊名字
2. 必须亲眼看到它失败
   • 没看到失败测试，就不知道它是否真的在测目标行为
   • 没看到失败，不算完成 TDD
3. 再写最小实现
   • 只写让当前测试通过所需的最小代码
   • 不顺手扩展、不顺手重构其它行为
4. 回跑测试并保持全绿
   • 当前测试要通过
   • 相关旧测试不能被带坏
5. 通过后再重构
   • 只有在绿灯后，才允许清理重复、改名或抽 helper

纪律约束

• 铁律：没有失败测试，就不要写生产代码
• 如果已经先写了实现，再想补测试，不要把它合理化成“这次先跳过”
• “先写实现再补测试”不是务实，而是在拿未来调试成本换眼前速度
• 如果你发现自己想说“这次先跳过”，停下来，回到失败测试
• 可以把结果写进当前任务记录，但不要把任何特定任务框架当成前提
• 没有任务容器时，也应把阶段结果落在 .quality/quality-check.md，而不是只写在回复里

参考

• 需要反模式清单时，读取 references/testing-anti-patterns.md
• 核心循环可概括为 红-绿-重构 / Red-Green-Refactor