PluginBench
Skill
Pass
Audit score 90

tdd

vinvcn/mattpocock-skills-zh-cn

Test-Driven Development: write failing tests first, then minimal code to pass them.

What is tdd?

TDD is a red-green-refactor loop for building features and fixing bugs by writing tests before implementation. Use this skill when you want to follow the TDD cycle, need guidance on what makes a good test, or are integrating tests into a codebase.

  • Write failing tests against public interfaces before implementing code
  • Identify and agree on seams (public boundaries) to test before writing tests
  • Distinguish good tests (behavior-driven, refactor-safe) from anti-patterns (implementation-coupled, tautological, horizontally-sliced)
  • Follow the red-green-refactor loop with one vertical slice per cycle
  • Align test names and vocabulary with project domain language via CONTEXT.md

How to install tdd

npx skills add https://github.com/vinvcn/mattpocock-skills-zh-cn --skill tdd
Claude Code
Cursor
Windsurf
Cline

How to use tdd

  1. 1.Before writing any test, identify and document the public seams (interfaces) you plan to test
  2. 2.Confirm the seams with the user or team to avoid testing everything
  3. 3.Write a failing test that verifies behavior through the public interface, not implementation details
  4. 4.Write minimal code to make the test pass (green)
  5. 5.Move to the next test; refactoring happens in code review, not in the red-green cycle
  6. 6.Check test names and vocabulary against CONTEXT.md to align with project domain language

Use cases

Good for
  • Building a new feature by writing tests first to clarify requirements
  • Fixing a bug by writing a failing test that reproduces it, then implementing the fix
  • Refactoring existing code while maintaining test coverage to ensure behavior doesn't change
  • Designing module boundaries and public interfaces by agreeing on seams upfront
  • Reviewing test quality to eliminate implementation-coupled or tautological assertions
Who it's for
  • Developers practicing or learning Test-Driven Development
  • Teams establishing TDD discipline and test quality standards
  • Code reviewers evaluating test coverage and test design
  • Architects designing public interfaces and module seams

tdd FAQ

What's the difference between a good test and a bad test?

A good test verifies behavior through public interfaces and reads like a specification (e.g., 'user can checkout with valid cart'); it survives refactors because it doesn't depend on implementation details. A bad test couples to internals, mocks private collaborators, or uses tautological assertions that can't disagree with the code.

What are seams and why do I need to agree on them first?

Seams are public boundaries where you can observe behavior without reaching into internals. You can't test everything, so identify and confirm seams upfront with the user to focus testing effort on critical paths and complex logic rather than every edge case.

Should I write all tests first, then all implementation?

No. Use vertical slices: one failing test → one minimal implementation → repeat. Horizontal slicing (all tests first) tests imagined behavior and makes tests insensitive to real changes. Each test is a tracer bullet responding to what you learned in the previous cycle.

When does refactoring happen in TDD?

Refactoring is not part of the red-green cycle. It belongs in the code review stage (see the code-review skill). The loop is: red (failing test) → green (minimal code) → next test.

How do I avoid implementation-coupled tests?

Test through public interfaces, not private methods or internal collaborators. Verify behavior, not shape. Use independent sources of truth for expected values (known-good literals, worked examples, specs) instead of recomputing them the same way the code does.

Full instructions (SKILL.md)

Source of truth, from vinvcn/mattpocock-skills-zh-cn.


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,mocking 规则见 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?"

当 interface 的形状本身就是问题所在时——module 该多深、seam 该放在哪里、interface 应该暴露什么——调用 Skill 工具并指定 codebase-design 获取词汇。它是 module、interface、depth、seam、adapter、leverage 和 locality 这些术语的共享来源,是供查阅的 reference,而不是要运行的 session。

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。