# Tdd Workflow > 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: `tomevault-io/tdd-workflow-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/tdd-workflow-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/tdd-workflow-2/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/tdd-workflow-2 --- # 测试驱动开发（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` 等 = "具体怎么写"（语言惯用法）。 --- > Source: [0xBB2B/bb-spec](https://github.com/0xBB2B/bb-spec) — distributed by [TomeVault](https://tomevault.io).