tdd

Guides test-driven development through red-green cycles with seam-based test design.

Updated Jul 16, 2026
One-click install
npx skills add https://github.com/The-Focus-AI/walking-thoughts --skill tdd-the-focus-ai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/The-Focus-AI/walking-thoughts/tree/main/.agents/skills/tdd
Command: npx skills add https://github.com/The-Focus-AI/walking-thoughts --skill tdd-the-focus-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after implementation often produces brittle, implementation-coupled tests that break during refactors and fail to verify real behavior. This Skill enforces a disciplined red-green loop so every test verifies observable behavior through public interfaces. ## Core Features & Use Cases - Red-Green Loop Rules: Enforces writing a failing test first, then only the minimal code to pass it, one vertical slice at a time. - Seam-Based Test Design: Defines tests only at pre-agreed public boundaries, confirmed with the user before any test is written. - Anti-Pattern Detection: Identifies implementation-coupled, tautological, and horizontally sliced tests with concrete good/bad examples. - Mocking Guidelines: Restricts mocks to system boundaries like external APIs, time, and file systems, with dependency injection patterns. - Use Case: When building a checkout feature, use this Skill to write one failing test for the public checkout interface, implement just enough code to pass, and repeat per slice. ## Quick Start Use the tdd skill to build this feature test-first, starting by agreeing on the seams we should test.

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 against a public interface first, then implement only enough code to make it pass. Repeat one vertical slice at a time, and keep refactoring out of the loop until the review stage.

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 collaborators.

When should I mock dependencies 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, and prefer dependency injection to make boundaries mockable.

Why do my tests break every time I refactor code?

Tests break during refactors when they are coupled to implementation details, such as mocking internal collaborators or asserting on call counts. Rewrite them to verify observable behavior through public interfaces so they survive internal changes.

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.