tdd

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

Updated Jun 26, 2026
One-click install
npx skills add https://github.com/dulltackle/kangkang-skills --skill tdd-dulltackle
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/dulltackle/kangkang-skills/tree/main/tdd
Command: npx skills add https://github.com/dulltackle/kangkang-skills --skill tdd-dulltackle

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 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: Helps you agree on public interface boundaries before writing any test, so testing effort lands on critical paths. - Anti-Pattern Detection: Flags implementation-coupled, tautological, and horizontally-sliced tests with concrete good/bad examples. - Mocking Guidance: Explains when to mock (system boundaries only) and how to design mockable interfaces via dependency injection and SDK-style APIs. - Use Case: When adding a checkout feature, use this Skill to define the seams with the user, write one failing behavior test, implement the minimal code to pass, and repeat until the feature is complete. ## Quick Start Use the tdd skill to build the new checkout 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 that describes desired behavior through a public interface, then write 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 testing and where should tests go?

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

When should I use mocks in unit tests?

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 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 on refactoring when they are coupled to implementation details, such as mocking internal collaborators, testing private methods, 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 how do I avoid it?

A tautological test recomputes its expected value the same way the implementation does, so it passes by construction and can never catch a bug. Use independent expected values from known literals, worked examples, or the specification instead.