tdd

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

Updated May 10, 2026
One-click install
npx skills add https://github.com/rexshihaoren/rexy_vibing_setup --skill tdd-rexshihaoren
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/rexshihaoren/rexy_vibing_setup/tree/main/docs/ai/skills/tdd
Command: npx skills add https://github.com/rexshihaoren/rexy_vibing_setup --skill tdd-rexshihaoren

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after implementation often produces brittle tests coupled to internal structure, while writing all tests upfront produces tests of imagined behavior. This Skill enforces a disciplined test-driven development workflow that keeps tests focused on observable behavior through public interfaces. ## Core Features & Use Cases - Red-Green-Refactor Loop: Implements one test and one minimal implementation per cycle using vertical tracer-bullet slices instead of horizontal batching. - Behavior-Focused Testing Guidance: Distinguishes good integration-style tests from implementation-coupled tests, with rules for when and how to mock at system boundaries. - Design References: Includes guidance on deep modules, interface design for testability, and post-cycle refactoring candidates. - Use Case: When adding a checkout feature, confirm the public interface and priority behaviors with the user, write one failing test, implement the minimal code to pass, and repeat until all behaviors are covered before refactoring. ## Quick Start Use the tdd skill to build the new shopping cart feature with a red-green-refactor workflow, 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 repeat for each remaining behavior. Only refactor after all tests pass, never while a test is failing.

Should I write all tests before implementation in TDD?▼

No. Writing all tests first is horizontal slicing and produces tests of imagined behavior coupled to data structures and signatures. Use vertical slices instead: one test, one implementation, repeated incrementally.

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 when I refactor code?▼

Tests break during refactoring when they verify implementation details like private methods, internal mock calls, or database state instead of observable behavior. Rewrite them to exercise public interfaces and assert on outcomes users care about.

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

Accept dependencies as parameters instead of constructing them internally, return results rather than producing side effects, and keep the surface area small. Dependency injection makes external services straightforward to substitute in tests.