# Tdd

> Build features or fix bugs test-first with vertical red-green slices through agreed public interfaces, including integration-test-driven work.

- Skill: `c1trusovo831/tdd` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add c1trusovo831/tdd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/c1trusovo831/tdd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: C1TRuSovo831 (https://skillmd.com/u/c1trusovo831)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/c1trusovo831/tdd

---


# Test-Driven Development

TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.

Use relevant `CONTEXT.md` entries when choosing domain names for tests or interfaces, and consult ADRs when the touched behavior depends on an architectural decision.

## Active workflow boundary

This skill supplies test design and the red-green discipline; it never expands
the active role's authority. Under a Herdr role contract:

- **Planner:** agree the public seam and acceptance signal read-only, then put
  the vertical-slice instructions in a self-contained same-team Coder handoff.
  Do not write tests or implementation, run state-changing harnesses, or use
  native sub-agents to bypass Herdr.
- **Coder:** perform the red-green slices only inside the current Planner
  handoff. Do not contact Reviewer, delegate, or choose unresolved user-visible
  behavior.
- **Reviewer:** inspect test quality and the observed red/green evidence
  read-only. Do not add tests, edit implementation, or run commands that may
  mutate the workspace.

Higher-priority sandbox, no-write, no-delegation, and task-scope constraints
always win over the loop described below.

## What a good test is

Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — "user can checkout with valid cart" tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure.

See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.

## Seams — where tests go

A **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.

**Test only at pre-agreed seams.** Before writing any test, record the seams under test. An explicit user request or an accepted handoff naming those seams supplies confirmation; do not ask again. If the seam is unresolved, confirm it with the user before writing the dependent tests. This keeps effort on agreed critical paths and complex logic.

Ask: "What's the public interface, and which seams should we test?"

When the shape of that interface is itself in question — how deep the module is, where the seam belongs, what the interface should expose — use the `/codebase-design` skill for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.

## Anti-patterns

- **Implementation-coupled** — mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
- **Tautological** — the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth — a known-good literal, a worked example, the spec.
- **Horizontal slicing** — writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead — one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.

## Rules of the loop

- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
- **One slice at a time.** One seam, one test, one minimal implementation per cycle.
- **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.