tdd

Enforce a red-green-refactor TDD loop with failing tests before production code changes.

198|19|Updated May 7, 2026
One-click install
npx skills add https://github.com/testdouble/han --skill tdd-testdouble
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/testdouble/han/tree/main/han-coding/skills/tdd
Command: npx skills add https://github.com/testdouble/han --skill tdd-testdouble

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

This TDD skill enforces a disciplined red-green-refactor loop, ensuring changes happen only after a failing test is observed and guiding production code to pass a single test at a time.

Core Features & Use Cases

  • Enforces the observed-failure gate before production code changes.
  • Manages outer (acceptance) and inner (red-green-refactor) loop cycles to drive end-to-end and unit behavior alignment.
  • Provides a repeatable workflow for evolving features with traceable test lists and refactor discipline.

Quick Start

Begin by listing the behaviors you want to validate, then convert one into a failing test and implement the minimal production code to make it pass.

Frequently Asked Questions about tdd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce a strict red-green-refactor loop when doing test-driven development?

A strict red-green-refactor loop enforces an observed-failure gate, requiring a failing test before any production code changes. You write a failing test first, implement minimal code to pass it, then refactor while keeping tests green.

What is the observed-failure gate in TDD and why does it matter?

The observed-failure gate in TDD ensures no production code changes happen until a failing test is actually observed. It prevents writing speculative code by guaranteeing every line of production code is driven by a validated test failure.

How do I manage acceptance and unit behavior cycles in test-driven development?

You manage acceptance and unit behavior cycles in test-driven development by using an outer and inner loop approach. The outer loop drives end-to-end acceptance tests while the inner loop applies the red-green-refactor cycle to individual unit behaviors.

Can I drive multiple behaviors at once during a TDD cycle?

No, this TDD cycle manages one behavior per loop iteration. Focusing on a single behavior ensures minimal production code implementation and maintains traceable alignment between the failing test and the specific feature being validated.

What is the best way to start a test-driven development workflow for a new feature?

The best way to start test-driven development for a new feature is listing the behaviors you want to validate. You then convert one behavior into a failing test and implement the minimal production code required to make it pass.

When should I not use a strict test-driven development approach?

You should avoid strict test-driven development when doing exploratory prototyping or working in environments where formal test coverage is not required. It is designed for projects needing formal test-driven development and adherence to canonical TDD processes.