tdd

Guides test-driven development using the red-green loop with seam-based testing.

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

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 test-driven development 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 enough code to pass it, one vertical slice at a time. - Seam Identification: Requires agreeing on public test boundaries (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 concrete good/bad examples in tests.md and mocking guidance in mocking.md. - Use Case: When adding a checkout feature, ask the assistant to build it test-first; it will confirm the seams, 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 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 observable behavior, then write only enough code to make it pass, and repeat one slice at a time. Refactoring belongs to a separate review stage, not the red-green implementation cycle.

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 at seams, never against internals, and all seams under test should be agreed with the user before writing any test.

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 to make boundaries easy to mock.

Why do my tests break every time I refactor code?

Tests break during refactoring when they are coupled to implementation details, such as mocking internal collaborators, testing private methods, or asserting on call counts. Tests should verify 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 such as a known literal, worked example, or specification.