tdd

Files (3)

• SKILL.md
• good-vs-bad-tests.md · references/
• refactoring.md · references/

SKILL.md (first lines)

# TDD — Test-Driven Development

Test-first development with vertical slices: one test → one implementation → repeat.

**Core principle:** Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.

## Anti-Pattern: Horizontal Slices

DO NOT write all tests first, then all implementation.

```
WRONG (horizontal):           RIGHT (vertical):
  RED:   test1, test2, test3    RED→GREEN: test1→impl1
  GREEN: impl1, impl2, impl3    RED→GREEN: test2→impl2
                                RED→GREEN: test3→impl3
```

Horizontal slicing produces tests coupled to _imagined_ behavior. Vertical slicing ensures each test responds to what you learned from the previous cycle.

## Process

### 1. Identify Behaviors

Read the issue's acceptance criteria. List the behaviors to test — not implementation steps, but observable outcomes.

_Example:_ "User can register with email and password" is a behavior. "Write RegisterHandler function" is an implementation step.

Prioritize critical paths and complex logic. You can't test everything.

### 2. RED — Write One Failing Test

Write ONE test for ONE behavior through the public interface:

```
[ ] Test describes a behavior, not an implementation detail
[ ] Test uses only the public API
[ ] Test compiles and fails (proves the behavior is missing)
```

See [good-vs-bad-tests.md](references/good-vs-bad-tests.md) for examples.

### 3. GREEN — Write Minimal Code

Write the minimum code to make the test pass. No more, no less.

```
[ ] Code is minimal — only what the current test needs
[ ] No speculative features for future tests
[ ] Test passes
```

### 4. Repeat RED→GREEN

For each remaining behavior: RED → GREEN. One at a time.

### 5. REFACTOR

After ALL tests are GREEN, look for refactor candidates. **Never refactor while RED.**

```
[ ] Extract duplication
[ ] Deepen modules (move complexity behind simple interfaces)
[ ] Apply SOLID where natural
[ ] Run tests after EACH refactor step
```

See [refactoring.md](references/refactoring.md) for guidance.

### 6. Commit

```bash
git add -A
git commit -m "feat: <summary of what was implemented>"
```

## Next Steps

After committing, suggest `code-review` for formal review.

## Tips

- This skill is stricter than `implement` — use `implement` for simpler tasks that don't need test-first discipline
- Convention rules live in the project's `CONTEXT.md`, not here

From atalariq/skills, MIT.

More from atalariq/skills