test-driven-development

Enforces red-green-refactor test-driven development workflow for features and bugfixes.

1|Updated May 3, 2021
One-click install
npx skills add https://github.com/leogurja/dotfiles --skill test-driven-development-leogurja
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/leogurja/dotfiles/tree/main/home/dot_agents/skills/test-driven-development
Command: npx skills add https://github.com/leogurja/dotfiles --skill test-driven-development-leogurja

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

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 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 signal you should delete code and start over. - 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 error first, watch it fail, then implement the minimal validation to make it pass. ## Quick Start Ask the agent 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 for a new feature?▼

Write one minimal failing test describing the desired behavior, run it and confirm it fails for the expected reason, then write the simplest code that makes it pass. Refactor only while all tests stay green, then repeat the cycle for the next behavior.

How do I write a failing test before implementation code exists?▼

Write the test against the API you wish existed, using a clear behavior-focused name and a hand-derived expected value. Run it to confirm it fails because the feature is missing, not because of a typo or setup error.

Should I write tests before or after fixing a bug?▼

Write the test first: create a failing test that reproduces the bug, watch it fail, then implement the minimal fix. This proves the test catches the bug and prevents regression when the code changes later.

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

Exceptions are limited to throwaway prototypes, generated code, and configuration files, and should be confirmed with your human partner. Exploration is fine, but the exploratory code should be discarded and rewritten test-first.

Why do tests written after implementation prove nothing?▼

Tests written after pass immediately, so you never watched them fail and cannot confirm they test the right thing. They are biased by the existing code and tend to verify remembered cases rather than discovered edge cases.

When should I use mocks instead of real components in tests?▼

Mock only slow or external operations after learning the real method's side effects, and keep everything the test depends on real. Never assert on the mock itself; if mock setup outgrows the test logic, switch to an integration test with real components.