tdd

Guides test-driven development through a red-green loop with per-cycle checklists.

20|2|Updated May 16, 2026
One-click install
npx skills add https://github.com/reddb-io/red-skills --skill tdd-reddb-io
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/reddb-io/red-skills/tree/main/plugins/dev/skills/engineering/tdd
Command: npx skills add https://github.com/reddb-io/red-skills --skill tdd-reddb-io

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often write tests after implementation or in bulk, producing tests coupled to internal structure that break on refactors and fail to catch real bugs. This Skill enforces a disciplined red-green TDD loop so tests verify observable behaviour through public interfaces. ## Core Features & Use Cases - Red-Green Loop Enforcement: One failing test, the minimum code to pass it, repeated one behaviour at a time with a per-cycle checklist. - Seam-Based Testing: Agree on public test boundaries before writing the first test, avoiding tests of private methods or mocked internals. - Anti-Pattern Guidance: Reference docs cover implementation-coupled tests, tautological assertions, mocking at system boundaries, deep modules, and interface design for testability. - Use Case: When building a new checkout feature, use this Skill to drive development test-first: confirm the public seam, write one failing test for cart confirmation, implement the minimum code, and repeat until all behaviours are covered. ## Quick Start Use the tdd skill to build this feature test-first with a red-green loop, one behaviour 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 a red-green loop?▼

Write one failing test for the next uncovered behaviour, then write the minimum code to pass it, and repeat. Confirm each cycle against a checklist before moving on, and never write all tests before all implementation.

What is a seam in test-driven development?▼

A seam is the public boundary where you test behaviour without reaching inside the implementation. Seams must be agreed upon before writing the first test, and each seam carries one behaviour per cycle.

When should I use mocks 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, since that couples tests to implementation details.

Why do my tests break when 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. Behaviour-focused tests through public interfaces survive internal changes.

What is a tautological test assertion?▼

A tautological assertion recomputes the expected value the same way the code computes it, so it passes by construction and proves nothing. Expected values must come from a literal, worked example, or the specification.