/tdd
测试驱动开发。适用于用户想用先写测试的方式构建功能或修复缺陷、提到 “red-green-refactor”,或需要集成测试时。
$ npx -y skills add vinvcn/mattpocock-skills-zh-cn --skill tdd --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/tdd
Context preview
The summary Claude sees to decide when to auto-load this skill.
测试驱动开发。适用于用户想用先写测试的方式构建功能或修复缺陷、提到 “red-green-refactor”,或需要集成测试时。
SKILL.md
tdd.SKILL.mdname: tdd
description: 测试驱动开发。适用于用户想用先写测试的方式构建功能或修复缺陷、提到 “red-green-refactor”,或需要集成测试时。
Test-Driven Development
TDD 是 red -> green loop。这个 skill 是让该 loop 产出值得保留的 tests 的 reference:什么是好 test、tests 应该放在哪里、anti-patterns,以及 loop 的规则。每个 cycle 前和 cycle 中都要参考这些内容,而不是事后才看。
探索 codebase 时,读取 `CONTEXT.md`(如果存在),让 test names 和 interface vocabulary 与项目 domain language 对齐,并尊重你触碰区域的 ADRs。
What a good test is
Tests 应通过 public interfaces 验证 behavior,而不是 implementation details。代码可以完全改变;tests 不该随之改变。一个好 test 读起来像 specification:"user can checkout with valid cart" 能清楚说明存在什么能力;因为它不关心 internal structure,所以能承受 refactors。
示例见 [tests.md](tests.md),mocking 规则见 [mocking.md](mocking.md)。
Seams — where tests go
**Seam** 是你测试的 public boundary:可以观察 behavior、但不伸手进入内部的 interface。Tests 放在 seams 上,绝不针对 internals。
**只测试预先认可的 seams。** 写任何 test 前,先写下要测试的 seams 并与用户确认。未经确认的 seam 不写 test。你无法测试所有东西;提前认可 seams,才能把测试精力放在 critical paths 和复杂 logic 上,而不是每个 edge case。
询问:"What's the public interface, and which seams should we test?"
Anti-patterns
- **Implementation-coupled** — mock internal collaborators、测试 private methods,或通过 side channel 验证(例如不用 interface 而直接查询 database)。特征是 refactor 时 test 失败,但 behavior 没变。
- **Tautological** — assertion 以和代码相同的方式重新计算 expected value(`expect(add(a, b)).toBe(a + b)`、手工按同一逻辑生成 snapshot、把 constant 断言等于它自己),因此天然 pass,永远无法与代码 disagree。Expected values 必须来自独立 source of truth:known-good literal、worked example 或 spec。
- **Horizontal slicing** — 先写所有 tests,再写所有 implementation。批量 tests 验证的是 _想象中的_ behavior:你测试的是东西的 _shape_,不是 user-facing behavior;tests 会对真实变化迟钝,并在理解 implementation 前承诺 test structure。改用 **vertical slices**:一个 test -> 一个 implementation -> repeat,每个 test 都是回应上一轮学习的 **tracer bullet**。
Rules of the loop
- **Red before green.** 先写 failing test,再只写足够让它通过的代码。不要预判未来 tests,也不要添加 speculative features。
- **One slice at a time.** 每个 cycle 只处理一个 seam、一个 test、一个 minimal implementation。
- **Refactoring is not part of the loop.** Refactoring 属于 review stage(见 `code-review` skill),不属于 red -> green implementation cycle。
Read more
name: tdd description: 测试驱动开发。适用于用户想用先写测试的方式构建功能或修复缺陷、提到 “red-green-refactor”,或需要集成测试时。
Test-Driven Development
TDD 是 red -> green loop。这个 skill 是让该 loop 产出值得保留的 tests 的 reference:什么是好 test、tests 应该放在哪里、anti-patterns,以及 loop 的规则。每个 cycle 前和 cycle 中都要参考这些内容,而不是事后才看。
探索 codebase 时,读取 `CONTEXT.md`(如果存在),让 test names 和 interface vocabulary 与项目 domain language 对齐,并尊重你触碰区域的 ADRs。
What a good test is
Tests 应通过 public interfaces 验证 behavior,而不是 implementation details。代码可以完全改变;tests 不该随之改变。一个好 test 读起来像 specification:"user can checkout with valid cart" 能清楚说明存在什么能力;因为它不关心 internal structure,所以能承受 refactors。
示例见 [tests.md](tests.md),mocking 规则见 [mocking.md](mocking.md)。
Seams — where tests go
**Seam** 是你测试的 public boundary:可以观察 behavior、但不伸手进入内部的 interface。Tests 放在 seams 上,绝不针对 internals。
**只测试预先认可的 seams。** 写任何 test 前,先写下要测试的 seams 并与用户确认。未经确认的 seam 不写 test。你无法测试所有东西;提前认可 seams,才能把测试精力放在 critical paths 和复杂 logic 上,而不是每个 edge case。
询问:"What's the public interface, and which seams should we test?"
Anti-patterns
- **Implementation-coupled** — mock internal collaborators、测试 private methods,或通过 side channel 验证(例如不用 interface 而直接查询 database)。特征是 refactor 时 test 失败,但 behavior 没变。
- **Tautological** — assertion 以和代码相同的方式重新计算 expected value(`expect(add(a, b)).toBe(a + b)`、手工按同一逻辑生成 snapshot、把 constant 断言等于它自己),因此天然 pass,永远无法与代码 disagree。Expected values 必须来自独立 source of truth:known-good literal、worked example 或 spec。
- **Horizontal slicing** — 先写所有 tests,再写所有 implementation。批量 tests 验证的是 _想象中的_ behavior:你测试的是东西的 _shape_,不是 user-facing behavior;tests 会对真实变化迟钝,并在理解 implementation 前承诺 test structure。改用 **vertical slices**:一个 test -> 一个 implementation -> repeat,每个 test 都是回应上一轮学习的 **tracer bullet**。
Rules of the loop
- **Red before green.** 先写 failing test,再只写足够让它通过的代码。不要预判未来 tests,也不要添加 speculative features。
- **One slice at a time.** 每个 cycle 只处理一个 seam、一个 test、一个 minimal implementation。
- **Refactoring is not part of the loop.** Refactoring 属于 review stage(见 `code-review` skill),不属于 red -> green implementation cycle。
Repo: vinvcn/mattpocock-skills-zh-cn
Other skills on mattpocock-skills.
- /ask-matt
询问当前情境适合哪个技能或流程;它是本仓库所有 skills 的路由器。
Open skill - /code-review
从固定点(commit、branch、tag 或 merge-base)开始,按 Standards(代码是否符合本仓库记录的编码标准?)和 Spec(代码是否符合来源 issue/PRD 的要求?)两个轴线审查变更。两个审查会在并行子代理中运行,并并排报告。适用于用户想审查 branch、PR、进行中的变更,或要求 “review since X” 时。
Open skill - /codebase-design
用于设计深模块的共享词汇。适用于用户想设计或改进模块接口、寻找深化机会、决定 seam 放在哪里、让代码更容易测试或更适合 AI 导航,或其他技能需要深模块词汇时。
Open skill - /diagnosing-bugs
面向棘手缺陷和性能回退的诊断循环。适用于用户说 “diagnose” / “debug this”,或报告某些东西 broken、throwing、failing、slow 时。
Open skill - /domain-modeling
构建并打磨项目的领域模型。适用于用户想明确领域术语或通用语言、记录架构决策,或其他技能需要维护领域模型时。
Open skill - /grill-with-docs
一个用来打磨计划或设计的持续追问式访谈,并在过程中创建文档(ADRs 和词汇表)。
Open skill

