---
name: Test-Driven Development
slug: test-driven-development-11
category: Quality
description: Test-Driven Development uses small red-green-refactor cycles to build or fix behavior test-first. Use it when you want integration tests, a failing-first loop, or a change guided by existing tests and repository conventions.
github: "https://github.com/stevesolun/ctx/tree/main/.agents/skills/tdd"
language: Python
stars: 578
forks: 71
install: "npx degit https://github.com/stevesolun/ctx/tree/main/.agents/skills/tdd ~/.claude/skills/tdd"
installs_to: ~/.claude/skills/tdd
source_path: .agents/skills/tdd/SKILL.md
collection_size: 25
category_size: 1354
collection_url: "https://dirskills.com/collections/stevesolun/ctx"
added: 2026-08-25T05:14:04.447Z
last_synced: 2026-08-25T05:14:04.447Z
canonical_url: "https://dirskills.com/skills/test-driven-development-11"
---

# Test-Driven Development

Test-Driven Development uses small red-green-refactor cycles to build or fix behavior test-first. Use it when you want integration tests, a failing-first loop, or a change guided by existing tests and repository conventions.

**Install:**

```bash
npx degit https://github.com/stevesolun/ctx/tree/main/.agents/skills/tdd ~/.claude/skills/tdd
```

## README

# Test-Driven Development

Use small red → green → refactor cycles when a test-first feedback loop is
practical. Treat repository conventions, existing tests, and the requested
behavior as authoritative.

## Loop

1. Identify one observable behavior and the seam through which callers see it.
2. Write the smallest meaningful test and confirm that it fails for the expected
   reason.
3. Add only enough implementation to make the test pass.
4. Refactor when doing so improves clarity or design; keep the suite green.
5. Repeat with the next vertical slice.

Infer seams from public interfaces and nearby tests. Ask the user only when
choosing a seam would materially change the product contract, cost, or scope.

## Judgment

- Prefer behavior-focused tests that survive internal refactors.
- Derive expected results from a specification, worked example, or other
  independent source rather than duplicating the implementation.
- Mock external or nondeterministic boundaries when useful; follow established
  repository patterns where they provide an adequate feedback loop.
- Prefer vertical slices over a speculative batch of tests. Batch closely
  related mechanical cases when that is clearer and faster.
- If a failing-first cycle is impractical—for example in legacy code with no
  usable seam—state the limitation and establish the nearest reliable
  characterization or integration test.

Read [tests.md](tests.md) for examples and [mocking.md](mocking.md) when deciding
whether and where to use test doubles.