test-driven-development

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

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/farslab/claude-skills --skill test-driven-development-farslab
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/farslab/claude-skills/tree/main/test-driven-development
Command: npx skills add https://github.com/farslab/claude-skills --skill test-driven-development-farslab

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Code written before tests often ships with unverified behavior, biased tests written after the fact, and regressions discovered only in production. This Skill enforces a strict test-first discipline so every feature and bugfix is proven by a failing test before implementation begins. ## Core Features & Use Cases - Red-Green-Refactor Enforcement: Guides the full cycle of writing a failing test, verifying it fails for the right reason, writing minimal code to pass, and refactoring while staying green. - Rationalization Detection: Lists common excuses for skipping TDD ("too simple to test", "I'll test after") with concrete rebuttals, plus red flags that trigger a restart. - Test Quality Rules: A companion reference defines how to write honest tests — naming the break each test catches, asserting real behavior instead of mocks, and running a mutation check. - Use Case: When fixing a bug where empty emails are accepted, write a failing test asserting the rejection, watch it fail, implement the minimal validation, and confirm the suite passes. ## Quick Start Use the test-driven-development skill to implement this feature by writing a failing test first, then the minimal code to make it pass.

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 confirm it fails because the feature is missing, then write the simplest code that passes. Refactor only while all tests stay green, then repeat for the next behavior.

How do I write a failing test for a bug fix?▼

Write a test that reproduces the bug by asserting the correct behavior, then run it to confirm it fails. Implement the minimal fix, verify the test passes and no other tests break, which also prevents the bug from regressing.

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

Exceptions are limited to throwaway prototypes, generated code, and configuration files, and only with explicit approval from your human partner. Exploration is allowed, but the exploratory code must be discarded and rewritten test-first.

Why should tests avoid asserting on mocks?▼

A mock assertion only proves the mock was present, not that the real component works. Assert the real component's observable behavior, mock only slow or external dependencies, and mirror the complete real data structure in any mock responses.

What should I do if I already wrote code before the test?▼

Delete the implementation and start over with a failing test. Keeping it as reference or adapting it biases the tests toward the existing code, so you never prove the test can actually catch the bug.