tdd

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

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after the fact or in bulk often produces brittle tests coupled to implementation details that break on every refactor. This Skill enforces a disciplined test-driven development workflow where tests verify observable behavior through public interfaces, so they survive internal changes. ## Core Features & Use Cases - Red-Green-Refactor Loop: Implements vertical slicing with tracer bullets—one test, one minimal implementation, repeated incrementally instead of writing all tests upfront. - Behavior-Focused Testing Guidance: Distinguishes good integration-style tests from bad implementation-coupled tests, with concrete examples of mocking boundaries and interface design. - Reference Material: Includes guidance on deep modules, interface design for testability, when to mock, and post-cycle refactoring candidates. - Use Case: When adding a checkout feature to an e-commerce app, use this Skill to plan which behaviors to test, write one failing test at a time through the public API, and refactor safely once all tests pass. ## Quick Start Use the tdd skill to build the new payment retry feature test-first, one behavior 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 one behavior at a time 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, 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 like internal function names, private methods, or mock call expectations. Rewrite them to verify behavior through public interfaces so they only fail when actual behavior changes.

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 slicing instead: alternate one test with one implementation so each test responds to what you learned from the previous cycle.