tdd-workflow
把测试作为设计工具，适合想提升设计质量与回归保障的团队。
跨语言的 TDD 流程规范，强调先写测试再实现（Red-Green-Refactor）。
一套跨语言的 TDD 工作法，强调先写测试再实现的 Red‑Green‑Refactor 循环，适用于新增/修改/删除业务逻辑代码（比如 .go/.py/.ts/.java 等）。用在你要以测试为主导来设计行为契约而不是事后验证的时候。特色是把测试当设计工具，明确哪些文件触发 TDD、哪些可以跳过，并给出覆盖率与顺序上的期待。
▸ 展开 SKILL.md 英文原文
Test-Driven Development (TDD) discipline — language- and scenario-agnostic. Covers Red-Green-Refactor, the add/modify/delete change scenarios, coverage expectations, and test-before-implementation ordering. TRIGGER when adding/modifying/deleting any business-logic source file (.go/.py/.ts/.tsx/.vue/.js/.rs/.java/.kt), or the user mentions TDD / test-first / writing tests. SKIP pure struct/interface/const/var files, docs, config, generated code. Complements language-specific testing skills (e.g. golang-testing). ｜ 测试驱动开发（TDD）通用纪律——跨语言、跨场景适用。覆盖 Red-Green-Refactor 循环、"新增 / 修改 / 删除"三种代码变更场景的标准流程、测试覆盖率期望、测试与实现的先后关系。TRIGGER when：新增、修改、删除任何业务逻辑代码（`.go` / `.py` / `.ts` / `.tsx` / `.vue` / `.js` / `.rs` / `.java` / `.kt` 等源文件）；或用户提到 "TDD" / "写测试" / "测试驱动" / "test-first"。SKIP when：纯结构体 / interface / 常量 / 变量定义文件、纯文档、纯配置、生成代码（`*_gen.go`、protobuf 产物等）。与各语言特化的 testing skill（如 `golang-testing`）互补：本 skill 是"通用纪律"，特化 skill 是"语言惯用法与测试组织"。 Use when this capability is needed.
帮我安装这个 skill：https://raw.githubusercontent.com/tomevault-io/skills-registry/main/0xbb2b--bb-spec--tdd-workflow/SKILL.mdcurl -fsSL "https://raw.githubusercontent.com/tomevault-io/skills-registry/main/0xbb2b--bb-spec--tdd-workflow/SKILL.md"# 测试驱动开发（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（改实现）→ 确认全 PAS