test-driven-development

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

Updated Oct 16, 2025
One-click install
npx skills add https://github.com/hugotown/dotfiles --skill test-driven-development-hugotown
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/hugotown/dotfiles/tree/main/agents/skills/test-driven-development
Command: npx skills add https://github.com/hugotown/dotfiles --skill test-driven-development-hugotown

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Developers often write production code first and bolt tests on afterward, producing tests that pass immediately and prove nothing. This Skill enforces a strict test-first discipline so every behavior is verified by a test that was watched failing before implementation. ## 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 explicit rebuttals to common excuses like "I'll test after" or "too simple to test", with red flags that trigger deleting code and starting 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, watch it fail, implement the minimal validation, and confirm all tests 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 step by step?▼

Follow the red-green-refactor cycle: write one minimal failing test, run it and confirm it fails for the expected reason, write the simplest code that passes, verify all tests pass, then refactor while keeping tests green. Repeat for each new behavior.

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

Write one test with a clear name describing a single behavior, using real code instead of mocks where possible. Derive expected values by hand as literals, never by reusing the code under test, and run the test to confirm it fails because the feature is missing.

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 exists, not that the component works. Assert the real component's behavior, mock only slow or external dependencies after learning their side effects, and mirror the complete real data structure in any mock response.

What should I do if I already wrote code before tests?▼

Delete the implementation and start over with a failing test. Keeping it as reference or adapting it while writing tests is effectively testing after, which produces biased tests that were never watched failing and may test the wrong thing.