tdd

Guides test-driven development using the red-green loop with behavior-focused tests.

Updated Aug 1, 2026
One-click install
npx skills add https://github.com/siegenthalerroger/.llmctl-marketplace --skill tdd-siegenthalerroger
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/siegenthalerroger/.llmctl-marketplace/tree/main/plugins/llmctl-workflow-0.2.1/skills/tdd
Command: npx skills add https://github.com/siegenthalerroger/.llmctl-marketplace --skill tdd-siegenthalerroger

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: Requires agreeing on public test boundaries (seams) with the user before any test is written. - Anti-Pattern Detection: Flags implementation-coupled, tautological, and horizontally-sliced tests with concrete good/bad examples. - Mocking Guidance: Defines when to mock (system boundaries only) and how to design mockable interfaces via dependency injection and SDK-style APIs. - Use Case: When building a checkout feature, use this Skill to write one failing behavior test at a confirmed seam, implement the minimal code to pass it, and repeat until the feature is complete. ## 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 first (red), then write only enough code to make it pass (green), and repeat one slice at a time. Do not anticipate future tests or add speculative features, and leave refactoring for the review stage.

What makes a good unit test that survives refactoring?▼

A good test verifies behavior through public interfaces, not implementation details, and reads like a specification of what the code does. It uses independent expected values from known literals or specs rather than recomputing results the way the code does.

When should I use mocks in testing?▼

Mock only at system boundaries such as external APIs, time, randomness, and sometimes databases or the file system. Never mock your own classes, internal collaborators, or anything you control, and prefer dependency injection to make boundaries mockable.

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 the public interface instead.

What is a tautological test and how do I avoid it?▼

A tautological test recomputes the expected value the same way the implementation does, so it passes by construction and can never catch bugs. Avoid it by deriving expected values from independent sources like known literals, worked examples, or the specification.