tdd

Guides test-driven development using the red-green-refactor loop with vertical slices.

Updated Apr 13, 2026
One-click install
npx skills add https://github.com/scoots31/engineering-playbook --skill tdd-scoots31
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/scoots31/engineering-playbook/tree/main/skills/tdd
Command: npx skills add https://github.com/scoots31/engineering-playbook --skill tdd-scoots31

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing tests after code often produces brittle tests coupled to implementation details that break on every refactor. This Skill enforces a disciplined test-first workflow so tests verify behavior through public interfaces and survive internal changes. ## Core Features & Use Cases - Red-Green-Refactor Loop: Drives one test at a time through failing test, minimal implementation, then refactoring, avoiding the anti-pattern of writing all tests before all code. - Behavior-Focused Test Design: Distinguishes good integration-style tests from implementation-coupled tests, with concrete TypeScript examples of each. - Interface and Mocking Guidance: Provides reference material on deep modules, dependency injection, and mocking only at system boundaries like external APIs and time. - Use Case: When building a checkout feature, write one failing test for a single behavior, implement just enough code to pass, then repeat for each remaining behavior before refactoring. ## Quick Start Use test-driven development to build this feature one behavior at a time with 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 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 unit tests?

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 do my tests break every time I refactor code?

Tests break on refactor when they are coupled to implementation details like internal function names or private methods. Rewrite them to exercise public interfaces and assert on observable outcomes instead of internal calls.

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 implementation, repeated, so each test responds to what the previous cycle revealed.