Test-Driven Development
Drives changes with a red-green-refactor loop so each behavior is proven by a test.
Install
npx skills add addyosmani/agent-skills --skill test-driven-development -g -a claude-code -y- Repository
- addyosmani/agent-skills113k
- Category
- Testing
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. Use when asked to add tests to a function, fix a bug in it or change its behavior, even when the code is pasted inline and the request does not mention tests.
Test-Driven Development
Overview
Write a failing test before writing the code that makes it pass. For bug fixes, reproduce the bug with a test before attempting a fix. Tests are proof, "seems right" is not done. A codebase with good tests is an AI agent's superpower; a codebase without tests is a liability.
When to Use
- Implementing any new logic or behavior
- Fixing any bug (the Prove-It Pattern)
- Modifying existing functionality
- Adding edge case handling
- Any change that could break existing behavior
When NOT to use: Pure configuration changes, documentation updates, or static content changes that have no behavioral impact.
Related: For browser-based changes, combine TDD with runtime verification using Chrome DevTools MCP, see the Browser Testing section below.
Discover the Stack First
The TDD cycle is universal; the commands are not. Before writing the first test, discover how this repository tests, and use its commands for every RED, GREEN, and verification step:
- Language and build system,
package.json,pom.xml/build.gradle,pyproject.toml,go.mod,Cargo.toml,Gemfile, aMakefile - Checked-in wrappers, prefer
./gradlew,./mvnw,make test, or a repo script over globally installed tools - Test framework and configuration, and how it runs a single focused test vs the full suite
- Existing conventions, where tests live, how files are named, what patterns neighboring tests follow
- Documented commands, README, CONTRIBUTING, and CI workflows show the commands that actually gate merges
Run the repository's focused-test command during the loop and its full-suite command before completion. Never assume a default like npm test, a Gradle, Cargo, or pytest project has its own equivalent.
The examples below use TypeScript for illustration; the workflow is identical in any language once you've discovered the project's own tooling.
