# Test-Driven Development

Drives changes with a red-green-refactor loop so each behavior is proven by a test.

- Repository: https://github.com/addyosmani/agent-skills (112533 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add addyosmani/agent-skills --skill test-driven-development -g -a claude-code -y`
Codex: `npx skills add addyosmani/agent-skills --skill test-driven-development -g -a codex -y`
Cursor: `npx skills add addyosmani/agent-skills --skill test-driven-development -g -a cursor -y`
Gemini CLI: `npx skills add addyosmani/agent-skills --skill test-driven-development -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add addyosmani/agent-skills`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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`, a `Makefile`
- **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.

## The TDD Cycle

The rest: https://github.com/addyosmani/agent-skills/blob/HEAD/skills/test-driven-development/SKILL.md