tdd

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

Updated Feb 22, 2024
One-click install
npx skills add https://github.com/tlipoca9/dotfiles --skill tdd-tlipoca9
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/tlipoca9/dotfiles/tree/main/home/dot_agents/skills/tdd
Command: npx skills add https://github.com/tlipoca9/dotfiles --skill tdd-tlipoca9

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-refactor 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: Requires agreeing on public test boundaries 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 building a checkout feature, use this Skill to define the public seams, write one failing behavior test like "user can checkout with valid cart", implement minimally, and repeat per slice. ## Quick Start Use the tdd skill to build this feature test-first, starting by agreeing on the public 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 on a new feature?▼

Start by agreeing on the public seams to test, then write one failing test describing observable behavior, implement only enough code to pass it, and repeat one vertical slice at a time. Avoid writing all tests before any implementation.

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, since that couples tests to implementation details.

What is a seam in software testing?▼

A seam is the public boundary where you observe behavior without reaching inside the code. Tests live at seams, never against internals, so they survive refactors that change structure but not behavior.

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, testing private methods, or asserting on call counts. Rewrite them to verify behavior through public interfaces only.

What is a tautological test and why is it bad?▼

A tautological test recomputes the expected value the same way the code 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.