Test-Driven Development (TDD)
This skill walks you through the test-first workflow: write a failing test, verify it fails correctly, implement just enough code to pass, then refactor while keeping tests green. You'll learn why test order matters, how to recognize when you're rationalizing shortcuts, and how to apply TDD to features, bug fixes, and refactoring across any language.
Test-Driven Development (TDD) teaches you to write failing tests first, then minimal code to pass them, ensuring every feature is properly verified.
AI-generated summary based on this skill's SKILL.md
Decision gist · record as of 2025-10-14
Test-Driven Development (TDD) teaches you to write failing tests first, then minimal code to pass them, ensuring every feature is properly verified. This skill walks you through the test-first workflow: write a failing test, verify it fails correctly, implement just enough code to pass, then refactor while keeping tests green. You'll learn why test order matters, how to recognize when you're rationalizing shortcuts, and how to apply TDD to features, bug fixes, and refactoring across any language.
Use it when
- Test-Driven Development begins by writing a failing test before any implementation.
- Test-Driven Development's test-first approach catches design issues early, prevents over-engineering.
Verify before relying
Read SKILL.md below before installing (1 file). Open directory: indexed for reading, not audited.
Install
obra/superpowers-skills/test-driven-development · repository language: TypeScript
Open directory. Skills are indexed for reading, not audited. Review a skill's body before installing it.
Frequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
What is the red-green-refactor cycle in Test-Driven Development?
Test-Driven Development's red-green-refactor cycle is the core workflow: first, write a failing test (red phase); second, implement just enough code to pass that test (green phase); third, refactor your code while keeping tests green. This cycle repeats for each feature or change, ensuring tests drive design and catch bugs early.
How do I start with TDD and write tests first?
Test-Driven Development begins by writing a failing test before any implementation. Define what your code should do, write a test that verifies that behavior, watch it fail, then write minimal code to make it pass. This test-first approach forces you to think about requirements upfront and creates a safety net for refactoring.
Why write tests first instead of testing after implementation?
Test-Driven Development's test-first approach catches design issues early, prevents over-engineering, and ensures every line of code has a test. Writing tests after implementation often leads to incomplete coverage and tests that merely validate existing code rather than driving better design. TDD makes refactoring safer and reduces debugging time.
Can I apply TDD to bug fixes and code changes?
Yes. Test-Driven Development applies directly to bug fixes: write a failing test that reproduces the bug, fix the code to pass it, then refactor. For code changes, write tests for the new behavior first, implement it, and refactor. This workflow ensures bugs stay fixed and changes don't break existing functionality.
What does Test-Driven Development mean by minimal code to pass tests?
Test-Driven Development's green phase requires writing only enough code to make the test pass—no extra features, no premature optimization. This constraint forces you to stay focused, prevents scope creep, and makes refactoring the next step. Once tests pass, you improve the code's design without changing its behavior.
How does Test-Driven Development help catch bugs and improve code quality?
Test-Driven Development improves quality by building a comprehensive test suite as you code, catching regressions immediately, and forcing you to think through edge cases. Tests serve as executable documentation and a safety net for refactoring, reducing bugs in production and making code easier to maintain and extend.
SKILL.md
Rendered from the published skill. Quoted content, verbatim.
Test-Driven Development (TDD)
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
When to Use
Always: - New features - Bug fixes - Refactoring - Behavior changes
Exceptions (ask your human partner): - Throwaway prototypes - Generated code - Configuration files
Thinking "skip TDD just this once"? Stop. That's rationalization.
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over.
No exceptions: - Don't keep it as "reference" - Don't "adapt" it while writing tests - Don't look at it - Delete means delete
Implement fresh from tests. Period.
Red-Green-Refactor
```dot digraph tdd_cycle { rankdir=LR; red [label="RED\nWrite failing test",
(truncated - see the full file via the links below)
File tree — 1 file
skills/testing/test-driven-development/SKILL.md
Let your AI agent find skills like this
Example. Real query, live index.
You found this page by searching. An agent finds it by wishing: SkillFed indexes 56,283 agent skills by what they can do, searchable in plain language.
wish › “Learn and implement test-driven development workflow”
Give your agent the search over MCP, or paste the wish link into any chat. No install? Search from any chat →
Related skills
UltraQA automates quality assurance by cycling through test execution, failure diagnosis, and targeted fixes until your specified goal succeeds. It supports tests, builds, linting, type checking, or custom verification patterns, with a maximum of five cycles and early exit on repeated failures. The workflow coordinates diagnosis and remediation across multiple agents to streamline the path to passing quality gates.
UltraQA automates the test-fix loop by running quality checks, analyzing what broke, and applying corrections across up to 5 cycles. Choose your goal—tests, build, lint, or type checking—and let it work toward success. It tracks progress, detects repeated failures, and exits when the goal is met or max cycles reached.
This skill activates during OpenSpec change implementation to enforce atomic test-driven development: every test—acceptance, unit, edge case, or helper—must fail for the right reason before production code is written to make it pass. Gherkin scenarios in spec.md are the canonical acceptance contract; every relevant scenario must become at least one test. The per-test state machine forbids batching, skipping refactor assessment, or shipping with uncovered scenarios.
TDD Mastery enforces the iron law of test-first development: write a failing test, verify it fails, implement minimal code to pass, then refactor. The skill drills the red-green-refactor cycle with no exceptions, rejecting any production code written before its corresponding test exists and has been observed failing.
tdd guides you through strict test-driven development using the red-green-refactor cycle: write a failing test, implement minimal code to pass it, then refactor. The skill enforces the discipline of writing tests before production code and provides framework-specific commands for multiple languages.
Systematic Debugging enforces a disciplined four-phase approach to troubleshooting: investigate the root cause through error analysis and evidence gathering, analyze patterns by comparing working and broken code, form and test hypotheses scientifically, then implement fixes. The skill emphasizes that symptom-level repairs fail—you must trace data flow, instrument multi-component systems, and stop after three failed attempts to question architectural soundness.
More skills testing-strategies (MIT) · ios-testing-patterns (MIT) · laravel-tdd (MIT)