tdd

Guides test-driven development using the red-green-refactor loop with behavior-focused integration tests.

Updated May 11, 2026
One-click install
npx skills add https://github.com/thachrocky12345/local-agent-train-workstation --skill tdd-thachrocky12345
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/thachrocky12345/local-agent-train-workstation/tree/main/.claude/skills/tdd
Command: npx skills add https://github.com/thachrocky12345/local-agent-train-workstation --skill tdd-thachrocky12345

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after implementation often produces brittle tests coupled to internal structure that break during refactors. This Skill enforces a disciplined test-first workflow where tests verify observable behavior through public interfaces, so they survive internal changes. ## Core Features & Use Cases - Red-Green-Refactor Workflow: Walks through planning, a tracer-bullet first test, an incremental one-test-at-a-time loop, and a final refactor pass. - Test Quality Guidance: Distinguishes behavior-focused integration tests from implementation-coupled tests, with rules for when and how to mock at system boundaries. - Interface Design Support: Provides principles for deep modules and testable interfaces using dependency injection and small surface areas. - Use Case: When building a new checkout feature, use this Skill to write one failing test for the first behavior, implement minimal code to pass it, then repeat per behavior before refactoring. ## Quick Start Use the tdd skill to build the new feature test-first, one behavior at a time through the red-green-refactor loop.

Frequently Asked Questions about tdd

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

FAQPage Schema
How do I practice test-driven development with red-green-refactor?

Write one failing test for a single behavior (red), write the minimal code to make it pass (green), then refactor while tests stay green. Repeat this cycle per behavior rather than writing all tests upfront.

What makes a good test in test-driven development?

Good tests are integration-style: they exercise real code paths through public APIs and describe what the system does, not how. They survive internal refactors because they avoid mocking internal collaborators or testing private methods.

When should I use mocks in unit tests?

Mock only at system boundaries such as external APIs, time, randomness, and sometimes databases or file systems. Never mock your own classes or internal collaborators, since that couples tests to implementation details.

Why do my tests break every time I refactor code?

Tests break during refactoring when they are coupled to implementation details, such as asserting on internal method calls or private functions. Rewrite them to verify observable behavior through public interfaces instead.

Should I write all tests before writing any implementation code?

No. Writing all tests first is horizontal slicing and produces tests of imagined behavior. Use vertical slices instead: one test, one minimal implementation, then repeat so each test responds to what you learned.