# Why does test driven development work better with an agent than without one?

Canonical URL: https://bestskillsforclaude.com/en/skills/test-driven-development
Language: en
Skill: test-driven-development
Publisher: Jesse Vincent (obra) (https://github.com/obra)
Source: https://github.com/obra/superpowers
License as stated by the publisher: MIT
Runtime: Claude Code and other supported coding agents
Category: Engineering discipline
Last reviewed: 2026-08-05

Because the failing test is the only thing that proves the agent understood the request.

## Short answer
The test-driven-development skill in Jesse Vincent's superpowers collection drives the agent through a red, green, refactor cycle: a failing test first, the smallest change that passes it, then cleanup. With an agent the failing test does double duty, because it also proves the agent understood the requirement before it started writing code.

Best for: Features and bug fixes with checkable behaviour, especially in code you cannot manually verify quickly.
Skip it if: You are exploring, prototyping or throwing the code away tomorrow.

## What to remember
- A failing test is a specification the agent cannot talk its way around.
- Watch the test fail. An agent that skips to green has usually written a test that cannot fail.
- Small cycles are the point. Large ones give the same false confidence as no tests.
- It is one skill inside a wider methodology, and works best with writing-plans alongside it.

## What it changes in practice
The hardest problem in agent assisted coding is not capability, it is verification. The agent believes it succeeded, the diff looks reasonable, and nobody has checked anything. A failing test converts belief into a mechanical fact.
It also front loads misunderstandings. If the agent writes a test that asserts the wrong behaviour, you find out in the first minute rather than after a large implementation is built on the misunderstanding.

## Where it disappoints
Tests that assert what the implementation happens to do are worse than no tests, because they lock a defect in place. Read the test, not just the result.
It is also poorly suited to exploration. When you do not yet know what correct looks like, writing the assertion first is guessing with extra steps.

## Install and first run
1. Install superpowers from obra/superpowers, published under MIT.
2. Insist on seeing the test fail before any implementation is written.
3. Keep each cycle to one small behaviour, because a large cycle hides which part actually failed.

## Questions
### Why insist on seeing the test fail?
A test that passes before the implementation exists is not testing anything. Watching it fail is the cheapest check available.

### Does this slow the agent down?
Per change, yes. Across a week it is usually faster, because it removes the rework caused by unverified changes.

### Is it separate from the rest of superpowers?
It is one skill in a larger methodology. It works alone, and works better next to writing-plans and verification-before-completion.

## Sources
- obra/superpowers on GitHub: https://github.com/obra/superpowers
- Agent skills directory listing: https://skills.sh

## Other languages
- Spanish: https://bestskillsforclaude.com/es/skills/test-driven-development
- Brazilian Portuguese: https://bestskillsforclaude.com/pt-br/skills/test-driven-development
- Japanese: https://bestskillsforclaude.com/ja/skills/test-driven-development