tdd

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

3|Updated Jan 9, 2026
One-click install
npx skills add https://github.com/craft-ts/craft-ts --skill tdd-craft-ts
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/craft-ts/craft-ts/tree/main/.agents/skills/tdd
Command: npx skills add https://github.com/craft-ts/craft-ts --skill tdd-craft-ts

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after implementation often produces brittle tests coupled to internal structure that break during refactors and fail to verify real behavior. This Skill enforces a disciplined test-driven development workflow where each test verifies observable behavior through public interfaces before any implementation exists. ## Core Features & Use Cases - Red-Green-Refactor Workflow: Structures development as vertical slices where one failing test drives one minimal implementation, repeated incrementally. - Behavior-Focused Testing Guidance: Distinguishes good integration-style tests from bad implementation-coupled tests, with concrete examples of each. - Design References: Includes guidance on deep modules, interface design for testability, mocking at system boundaries, and post-cycle refactoring candidates. - Use Case: When building a new checkout feature, use this Skill to write one failing test for the first behavior, implement the minimal code to pass it, then repeat for each remaining behavior before refactoring. ## Quick Start Use the tdd skill to build the new feature using test-driven development with one behavior-tested cycle at a time.

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 is the difference between good and bad unit tests?▼

Good tests verify observable behavior through public interfaces and survive internal refactors. Bad tests mock internal collaborators, test private methods, or assert on call counts, breaking whenever implementation changes without behavior changing.

When should I use mocks in testing?▼

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

Why should I avoid writing all tests before implementation?▼

Writing all tests first (horizontal slicing) produces tests of imagined behavior that are insensitive to real changes. Vertical slices with one test then one implementation let each test respond to what you learned from the previous cycle.

How do I design interfaces that are easy to test?▼

Accept dependencies as parameters instead of creating them internally, return results instead of producing side effects, and keep the surface area small. Dependency injection makes external boundaries trivially mockable.