tdd

Guide test-driven development with red-green-refactor cycles and seam identification.

45|2|Updated Apr 24, 2026

Search Tags:#testing #tdd #refactoring #mocking #unit-testing #software-engineering

Ready to run

npx skills add https://github.com/hachej/boring-ui --skill tdd-hachej

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/hachej/boring-ui/tree/main/.agents/skill-library/mattpocock/tdd
Command: npx skills add https://github.com/hachej/boring-ui --skill tdd-hachej

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill addresses the challenge of writing maintainable, high-quality code by enforcing a disciplined test-driven development cycle that prevents implementation-coupled tests and tautological assertions.

Core Features & Use Cases

Red-Green-Refactor Guidance: Provides strict rules for the TDD loop to ensure tests are written before implementation and refactoring is handled separately.
Seam Identification: Helps developers identify public interfaces (seams) to test behavior rather than internal implementation details.
Mocking Best Practices: Offers clear guidelines on when to mock system boundaries and how to design for mockability using dependency injection.

Quick Start

Use the tdd skill to help me define the public seams for my new user authentication module before I write any tests.

Frequently Asked Questions about tdd

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

FAQPage Schema

How do I start test-driven development for a new module?▼

Test-driven development begins by identifying public interfaces, or seams, to test behavior. You define the expected behavior at these boundaries before writing any implementation, ensuring clean architectural separation and refactor-resilient code.

What is the red-green-refactor loop in unit testing?▼

The red-green-refactor loop is a strict test-driven development cycle. You write a failing behavior test (red), implement the minimum code to pass it (green), and then refactor the code separately to maintain high test coverage and clean boundaries.

When should I use mocking in unit testing?▼

Mocking should be used exclusively at system boundaries. You design for mockability using dependency injection to replace external dependencies, avoiding implementation-detail mocking that couples tests to internal code structure.

How do I write refactor-resilient tests that don't break easily?▼

Refactor-resilient tests focus on behavior at defined system seams rather than internal implementation details. By avoiding implementation-coupled assertions and tautological tests, your unit tests remain valid during code refactoring.

Does test-driven development work for existing code that needs refactoring?▼

Test-driven development applies to refactoring tasks by guiding the creation of behavior-focused tests at defined seams. This enforces a disciplined cycle that prevents implementation-coupled tests and ensures high test coverage before modifying existing logic.

Why do my unit tests break when I refactor my code?▼

Unit tests break during refactoring when they are coupled to internal implementation details rather than public behavior. By testing defined system seams and avoiding implementation-detail mocking, you prevent tautological assertions and maintain refactor-resilient code.