Skip to content
Development
Skill

/tdd

Test-driven development. Use when building a feature or fixing a bug test-first, when the user asks for red-green-refactor, or when a change needs its tests written before its implementation.

From plugin
bendrucker-claude
1685 skills10 agents1 MCP
Install
$ npx -y skills add bendrucker/claude --skill tdd --agent claude-code

How 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.

Test-driven development. Use when building a feature or fixing a bug test-first, when the user asks for red-green-refactor, or when a change needs its tests written before its implementation.

SKILL.md

tdd.SKILL.md
name: tdd
description: Test-driven development. Use when building a feature or fixing a bug test-first, when the user asks for red-green-refactor, or when a change needs its tests written before its implementation.
disable-model-invocation: true

Test-Driven Development

Seams

A seam is where a module's interface lives: the place a caller observes behavior without reaching inside. Tests run at seams.

Before writing any test, ask the user what the public interface is and which seams to test. Write no test at an unconfirmed seam.

When the interface shape is itself in question, read [`LANGUAGE.md`](../improve-codebase-architecture/LANGUAGE.md) for the vocabulary: module, interface, implementation, depth, seam, adapter, locality.

The Loop

One seam, one test, one minimal implementation per cycle.

1. Write one failing test at a confirmed seam. Run it and confirm it fails for the reason you expect. 2. Write only enough code to pass it. Anticipate no later test and add no speculative feature. 3. Return to step 1 with what the cycle taught.

Refactoring belongs to review, outside the loop: `review:code` for correctness, `simplify` for reuse and shape.

The work is done when every confirmed seam has a test that failed before its implementation existed.

What a Good Test Is

Verify behavior through the interface. Name the test as a specification: "user can checkout with valid cart" names a capability. Use the domain language the surrounding code uses.

See [references/tests.md](references/tests.md) for good and bad pairs, and [references/mocking.md](references/mocking.md) for which seams get a substitute adapter.

Anti-Patterns

Implementation-Coupled

The test substitutes an internal collaborator, exercises a private method, or verifies through a side channel such as querying the database instead of reading back through the interface. The tell: a refactor breaks the test while behavior is unchanged.

Tautological

The assertion recomputes the expected value the way the code computes it: `expect(add(a, b)).toBe(a + b)`, a snapshot worked out by hand through the same steps, a constant asserted equal to itself. Take expected values from an independent source: a known-good literal, a worked example, the spec.

Horizontal Slicing

Writing every test first, then every implementation. Work in vertical slices: one test, one implementation, repeat, each cycle responding to what the last one taught.

---

Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) `skills/engineering/tdd/SKILL.md` at `6654f6b`, MIT.

Read more
Ships withbendrucker-claude

My personal plugin marketplace for Claude Code, Anthropic's AI coding assistant.

Get the whole plugin

Other skills on bendrucker-claude.