addyosmani/agent-skills/test-driven-development
- community
Checking that the SKILL.md file is still in the repository.
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.
Install
npx vskill@latest install addyosmani/agent-skills/test-driven-developmentSKILL.md
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.
The TDD Cycle
Step 1: RED — Write a Failing Test
Write the test first. It must fail. A test that passes immediately proves nothing.
Step 2: GREEN — Make It Pass
Write the minimum code to make the test pass. Don't over-engineer:
Step 3: REFACTOR — Clean Up
With tests green, improve the code without changing behavior:
- Extract shared logic
- Improve naming
- Remove duplication
- Optimize if necessary
Run tests after every refactor step to confirm nothing broke.
The Prove-It Pattern (Bug Fixes)
When a bug is reported, do not start by trying to fix it. Start by writing a test that reproduces it.
Example:
The Test Pyramid
Invest testing effort according to the pyramid — most tests should be small and fast, with progressively fewer tests at higher levels:
The Beyonce Rule: If you liked it, you should have put a test on it. Infrastructure changes, refactoring, and migrations are not responsible for catching your bugs — your tests are. If a change breaks your code and you didn't have a test for it, that's on you.
Test Sizes (Resource Model)
Beyond the pyramid levels, classify tests by what resources they consume:
| Size | Constraints | Speed | Example | |
|---|---|---|---|---|
| Small | Single process, no I/O, no network, no database | Milliseconds | Pure function tests, data transforms | |
| Medium | Multi-process OK, localhost only, no external services | Seconds | API tests with test DB, component tests | |
| Large | Multi-machine OK, external services allowed | Minutes | E2E tests, performance benchmarks, staging integration |
Small tests should make up the vast majority of your suite. They're fast, reliable, and easy to debug when they fail.
Decision Guide
Writing Good Tests
Test State, Not Interactions
Assert on the outcome of an operation, not on which methods were called internally. Tests that verify method call sequences break when you refactor, even if the behavior is unchanged.
DAMP Over DRY in Tests
In production code, DRY (Don't Repeat Yourself) is usually right. In tests, DAMP (Descriptive And Meaningful Phrases) is better. A test should read like a specification — each test should tell a complete story without requiring the reader to trace through shared helpers.
Duplication in tests is acceptable when it makes each test independently understandable.
Prefer Real Implementations Over Mocks
Use the simplest test double that gets the job done. The more your tests use real code, the more confidence they provide.
Use mocks only when: the real implementation is too slow, non-deterministic, or has side effects you can't control (external APIs, email sending). Over-mocking creates tests that pass while production breaks.
Use the Arrange-Act-Assert Pattern
One Assertion Per Concept
Name Tests Descriptively
Test Anti-Patterns to Avoid
| Anti-Pattern | Problem | Fix | |
|---|---|---|---|
| Testing implementation details | Tests break when refactoring even if behavior is unchanged | Test inputs and outputs, not internal structure | |
| Flaky tests (timing, order-dependent) | Erode trust in the test suite | Use deterministic assertions, isolate test state | |
| Testing framework code | Wastes time testing third-party behavior | Only test YOUR code | |
| Snapshot abuse | Large snapshots nobody reviews, break on any change | Use snapshots sparingly and review every change | |
| No test isolation | Tests pass individually but fail together | Each test sets up and tears down its own state | |
| Mocking everything | Tests pass but production breaks | Prefer real implementations > fakes > stubs > mocks. Mock only at boundaries where real deps are slow or non-deterministic |
Browser Testing with DevTools
For anything that runs in a browser, unit tests alone aren't enough — you need runtime verification. Use Chrome DevTools MCP to give your agent eyes into the browser: DOM inspection, console logs, network requests, performance traces, and screenshots.
The DevTools Debugging Workflow
What to Check
This is the start of the file. Read the full SKILL.md on GitHub.
Security
- Security scanPassedPattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/test-driven-development/SKILL.md
Popularity
- Repository stars
- 99,045
- Repository forks
- 10,398
- 7-day trend score
- 58
Stars and forks are for the whole GitHub repository, not this skill alone. Refreshed 23 Mar 2026, 7 months ago.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/addyosmani/agent-skills/test-driven-development)