test-driven-development

Enforces red-green-refactor test-driven development workflow before writing production code.

Updated Aug 22, 2026

Search Tags:#code quality #tdd #unit testing #bug fixing #mocking #red green refactor #test first

Ready to run

npx skills add https://github.com/mewishu/awesome-skills --skill test-driven-development-mewishu

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/mewishu/awesome-skills/tree/main/skills/pattern/iterative-loop/test-driven-development
Command: npx skills add https://github.com/mewishu/awesome-skills --skill test-driven-development-mewishu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents untested or poorly tested production code by enforcing a strict test-first discipline, eliminating the common habit of writing tests after implementation that prove nothing. ## Core Features & Use Cases - Red-Green-Refactor Cycle: Guides writing a failing test, verifying it fails for the right reason, writing minimal code to pass, then refactoring while staying green. - Rationalization Countermeasures: Provides a table of common excuses for skipping TDD and concrete rebuttals, plus red flags that signal you must delete code and start over. - Test Quality Rules: A companion reference defines how to write honest tests that name the break they catch, exercise real behavior instead of mocks, and pass a mutation check. - Use Case: When fixing a bug where empty emails are accepted, write a failing test asserting the rejection error, watch it fail, implement the minimal validation, and confirm all tests pass. ## Quick Start Ask the AI to implement a new feature or bugfix using strict 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 step by step?▼

Write one minimal failing test describing the desired behavior, run it and confirm it fails for the expected reason, write the simplest code that makes it pass, verify all tests pass, then refactor while keeping tests green. Repeat for each new behavior.

How do I write good unit tests that actually catch bugs?▼

Name the specific production change that would make each test fail, derive expected values by hand rather than reusing the code under test, and assert on real behavior instead of mock interactions. Finish with a mutation check: mentally break the code and confirm a test catches it.

When is it acceptable to skip test-driven development?▼

Only for throwaway prototypes, generated code, or configuration files, and only with explicit approval from your human partner. Exploratory coding is allowed, but the exploration must be discarded and the real implementation restarted with TDD.

When should I use mocks in unit tests?▼

Mock only slow or external operations after learning the real method's side effects, keeping everything the test depends on real. Never assert on the mock itself, mirror the complete real data structure, and prefer integration tests with real components when mock setup grows large.

Why should tests be written before implementation code?▼

Tests written after implementation pass immediately, which proves nothing about whether they test the right thing. Watching a test fail first confirms it can catch the bug, and test-first design keeps interfaces simple because hard-to-test code signals unclear design.