test-driven-development

Enforces red-green-refactor test-driven development cycles for features, bugfixes, and code modifications.

Updated Jul 22, 2026
One-click install
npx skills add https://github.com/johnstegeman/pi-packages --skill test-driven-development-johnstegeman
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/johnstegeman/pi-packages/tree/main/packages/pi-superpowers-plus/skills/test-driven-development
Command: npx skills add https://github.com/johnstegeman/pi-packages --skill test-driven-development-johnstegeman

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? It prevents writing production code without failing tests first, eliminating unverified implementations, tests-after-the-fact bias, and regressions from untested bugfixes. ## Core Features & Use Cases - Three TDD Scenarios: Full red-green-refactor for new features, before/after test verification for modifying tested code, and judgment-based handling for trivial changes. - Iron Law Enforcement: Mandates deleting any production code written before a failing test, with a rationalization table countering common excuses. - Test Quality Guidance: Companion references cover naming the break each test catches, exercising real code instead of mocks, and running a mutation check before finishing. - Use Case: When implementing a retry mechanism, write a failing test asserting three attempts, watch it fail, write minimal retry logic, watch it pass, then refactor. ## Quick Start Ask the agent to implement a new feature or bugfix using test-driven development with a failing test written first.

Frequently Asked Questions about test-driven-development

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I practice test-driven development on a new feature?

Write one minimal failing test describing the desired behavior, run it and watch it fail for the right reason, then write the simplest code to pass it. Refactor only after green, and repeat the cycle for each new behavior.

How should I modify code that already has tests?

Run the existing tests first to confirm they are green, make your change, then run them again to confirm they still pass. If your change is not covered by existing tests, add a failing test for it before implementing.

When is it acceptable to skip writing a test first?

Only for genuinely trivial changes like typo fixes, string changes, or config tweaks, where you run relevant existing tests afterward. If the change touches any logic, it is not trivial and requires the full TDD cycle.

Why must I delete code written before the test?

Code written before a failing test was never verified, and keeping it as reference leads to adapting it rather than testing first. Deleting it and reimplementing from failing tests proves the tests actually exercise the behavior.

What makes a good unit test versus a bad one?

A good test names the production bug it would catch, derives expected values by hand rather than from the code under test, and exercises real components instead of asserting on mocks. Finish with a mutation check: each realistic code mutation should fail at least one test.