# Tdd

> Test-driven development with red-green-refactor. Use when the user wants to build features or fix bugs test-first, or mentions unit, integration, or red-green-refactor tests.

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

---


# Test-Driven Development

Build features and fix bugs one vertical slice at a time, using tests as the feedback loop.

## Core principle

Tests verify behavior through public interfaces, not implementation details. If you refactor and the test breaks without behavior changing, the test was wrong.

## Anti-pattern: horizontal slices

Do not write all tests first, then all implementation. Write one test, make it pass, then repeat.

```
Wrong:  RED test1, test2, test3 -> GREEN impl1, impl2, impl3
Right:  RED test1 -> GREEN impl1 -> RED test2 -> GREEN impl2 -> ...
```

## Workflow

### 1. Plan

- Confirm the interface changes with the user.
- Confirm which behaviors to test. You cannot test everything.
- List behaviors as observable outcomes, not implementation steps.
- Get user approval before writing code.

### 2. Tracer bullet

Write one test for one behavior. Watch it fail. Write the minimal code to make it pass.

### 3. Incremental loop

For each remaining behavior:

- Write the next test.
- Make it pass with minimal code.
- Do not anticipate future tests.

### 4. Refactor

After all tests pass:

- Extract duplication.
- Deepen modules: small interface, deep implementation.
- Run tests after each refactor step.

Never refactor while RED.

## Checklist per cycle

- [ ] Test describes behavior, not implementation.
- [ ] Test uses the public interface.
- [ ] Test would survive an internal refactor.
- [ ] Code is minimal for this test.
- [ ] No speculative features added.

## Rules

- Write tests before implementation for new behavior.
- Use type hints and clear names.
- Keep functions small and single-purpose.
- Fail fast with clear error messages.