tdd-workflow

测试驱动开发（TDD）纪律

适用于：所有语言、所有业务逻辑代码的新增 / 修改 / 删除变更。

核心：测试是设计工具，不是验证工具。 先写测试迫使你以调用方视角想清楚行为契约。

0. 触发与跳过

TRIGGER：新增/修改/删除业务逻辑源文件（.go/.py/.ts/.tsx/.vue/.js/.rs/.java/.kt 等）；用户提到 TDD/写测试/test-first。 SKIP：纯 struct/interface/enum/常量定义、生成代码、纯文档、纯配置、vendor/node_modules。

---

1. Red-Green-Refactor 循环（强制）

RED      → 写一个失败测试，明确行为预期 → 跑测试确认 FAIL
GREEN    → 写最小实现让测试通过 → 跑测试确认 PASS
REFACTOR → 测试保护下重构 → 跑测试确认仍 PASS

RED 要点：真的失败（断言不通过，不是编译错误）；一次只引入一个最小行为预期。 GREEN 要点：最小实现（允许傻瓜实现）；不提前写未覆盖的代码。 REFACTOR 要点：不新增行为；每次小改动后跑测试。

---

2. 三种变更场景

新增功能

RED（写失败测试）→ GREEN（最小实现）→ REFACTOR → 下一个行为。禁止先写实现再补测试。

修改功能

RED（先改/增测试反映新预期）→ 确认 FAIL → GREEN（改实现）→ 确认全 PASS。禁止先改实现再调测试。

删除代码

检查无依赖 → 先删测试 → 再删实现 → 跑完整测试套件。禁止先删实现导致编译失败再被动删测试。

---

3. 覆盖率

整体期望 80%+（期望而非硬拦截，显著下降需在 PR 说明中解释）。

优先级：业务逻辑层 > 关键纯函数 > 错误分支 > 边界条件 > 集成边界。 不强求：纯定义文件、框架样板、一次性脚本。

---

4. 测试作为行为契约

• 需求不清时：先写测试明确预期 → 拿给用户确认 → 再实现
• 测试要满足：可读（名字描述行为）/ 独立（不依赖顺序）/ 可重现 / 快

---

5. 禁止的反模式

• ❌ 先写实现再补测试
• ❌ 超大集成测试代替基础单测
• ❌ "函数被调用一次"当通过
• ❌ 只覆盖 happy path
• ❌ 测试失败时放宽断言

---

6. 与语言特化 skill 的关系

本 skill = "做不做、按什么顺序做"（通用纪律）。golang-testing 等 = "具体怎么写"（语言惯用法）。