test-driven-development

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

1|Updated Dec 30, 2025
One-click install
npx skills add https://github.com/Fidasek009/agents --skill test-driven-development-fidasek009
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/Fidasek009/agents/tree/main/.agents/skills/test-driven-development
Command: npx skills add https://github.com/Fidasek009/agents --skill test-driven-development-fidasek009

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code written before tests often ships untested, and tests written after implementation pass immediately without proving they can catch bugs. This Skill enforces a strict test-first discipline so every behavior change is verified by a failing test before any production code exists. ## Core Features & Use Cases - Red-Green-Refactor Enforcement: Guides the full TDD cycle — write a failing test, verify it fails for the right reason, write minimal code to pass, then refactor while staying green. - Rationalization Countermeasures: Provides a table of common excuses ("too simple to test", "I'll test after") with rebuttals, plus red flags that trigger deleting code and starting over. - Test Quality Rules: A companion reference defines how to write honest tests — name the production change each test catches, assert on real behavior instead of mocks, and run a mutation check before finishing. - 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 Use the test-driven-development skill to implement this feature by writing a failing test first and following the red-green-refactor cycle.

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 to confirm it fails for the right reason, then write the simplest code that passes. Refactor only while tests stay green, then repeat the cycle for the next behavior.

How do I write a good failing test before implementation?▼

Name the production change that would make the test fail, derive expected values by hand as literals, and assert on real behavior rather than mock interactions. Watch the test fail and confirm the failure is due to the missing feature, not a typo.

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

Throwaway prototypes, generated code, and configuration files may be exceptions, but only with explicit approval from your human partner. Thinking "skip TDD just this once" is treated as rationalization, not a valid reason.

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 while writing tests counts as testing after, which never proves the test can catch the bug.

When should I use mocks in unit tests?▼

Mock only slow or external dependencies after learning the real method's side effects, and mirror the complete real data structure. Never assert on the mock itself; if mock setup outgrows the test logic, switch to an integration test with real components.