tdd

Guides test-driven development through the red-green-refactor loop with seam-based testing rules.

1|Updated Jul 2, 2026
One-click install
npx skills add https://github.com/filippolmt/skills --skill tdd-filippolmt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/filippolmt/skills/tree/main/skills/tdd
Command: npx skills add https://github.com/filippolmt/skills --skill tdd-filippolmt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after the fact often produces brittle, implementation-coupled tests that break on every refactor. This Skill enforces a disciplined test-first workflow so tests verify behavior through public interfaces and survive code changes. ## Core Features & Use Cases - Red-Green Loop Rules: Enforces writing a failing test first, then only enough code to pass it, one vertical slice at a time. - Seam Identification: Requires agreeing on public interface seams with the user before any test is written, focusing effort on critical paths. - Anti-Pattern Detection: Flags implementation-coupled, tautological, and horizontally-sliced tests, with mocking guidelines limited to system boundaries. - Use Case: When asked to add a checkout feature, the Skill drives one failing integration test through the public API, then the minimal implementation, repeating per slice instead of bulk-writing tests. ## Quick Start Ask the assistant to build a new feature using test-driven development 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 the red-green-refactor loop?

Write one failing test against a public interface first, then write only enough code to make it pass, and repeat one slice at a time. Refactoring is deferred to a separate review stage rather than mixed into the loop.

What is a seam in test-driven development?

A seam is the public boundary where you observe behavior without reaching inside the code. Tests live only at pre-agreed seams confirmed with the user, never against private methods or internal structure.

When should I mock dependencies in unit tests?

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

Why do my tests break every time I refactor code?

Tests break on refactor when they are coupled to implementation details, such as mocking internal collaborators or asserting on call counts. Behavior-focused tests through public interfaces survive internal changes because they verify what the code does, not how.

What is a tautological test and why is it bad?

A tautological test recomputes the expected value the same way the implementation does, so it passes by construction and can never catch a bug. Expected values must come from an independent source like a known literal or worked example.