tdd

Guides test-driven development using the red-green loop with behavior-focused tests at public interfaces.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after implementation often produces brittle tests coupled to internal structure that break on every refactor. This Skill enforces a disciplined red-green TDD loop so tests verify observable behavior through public interfaces and survive code changes. ## Core Features & Use Cases - Red-Green Loop Rules: Write the failing test first, then only enough code to pass it, one vertical slice at a time. - Seam Identification: Agree on public interface boundaries with the user before writing any test, focusing effort on critical paths. - Anti-Pattern Detection: Avoid implementation-coupled, tautological, and horizontally-sliced tests using concrete good/bad examples in tests.md and mocking guidance in mocking.md. - Use Case: When adding a checkout feature, ask the AI to drive it test-first: it will confirm the seams with you, write one failing behavior test, implement the minimal code to pass, and repeat per slice. ## Quick Start Use the tdd skill to build the new shopping cart checkout feature test-first, one red-green 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 the red-green loop?▼

Write one failing test that describes desired behavior through a public interface, then write only enough code to make it pass. Repeat one vertical slice at a time rather than writing all tests upfront, and defer refactoring to a separate review stage.

What makes a good unit test versus a bad test?▼

Good tests verify observable behavior through public APIs, read like specifications, and survive refactors. Bad tests mock internal collaborators, test private methods, assert on call counts, or recompute expected values the same way the implementation does.

When should I use mocks in testing?▼

Mock only at system boundaries such as external APIs, time, randomness, and sometimes databases or the file system. Never mock your own classes or internal collaborators, and design boundaries with dependency injection and SDK-style interfaces for easy mocking.

Why do my tests break every time I refactor code?▼

Tests break on refactoring when they are coupled to implementation details like private methods, internal mocks, or call ordering. Rewrite them to assert behavior through public interfaces so internal restructuring leaves them untouched.

What is a tautological test and how do I avoid it?▼

A tautological test computes its expected value the same way the code under test does, so it passes by construction and can never catch bugs. Use independent expected values such as known literals, worked examples, or specification-derived results.