tdd

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

Updated Aug 13, 2026
One-click install
npx skills add https://github.com/Evolutionary-Leadership/harness --skill tdd-evolutionary-leadership
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/Evolutionary-Leadership/harness/tree/main/.claude/skills/tdd
Command: npx skills add https://github.com/Evolutionary-Leadership/harness --skill tdd-evolutionary-leadership

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after code often produces brittle, implementation-coupled tests that break on every refactor. This Skill enforces a disciplined red-green test-driven development loop so tests verify behavior through public interfaces and survive refactors. ## 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-Based Testing: Defines tests at pre-agreed public interface seams, confirmed with the user before any test is written. - Anti-Pattern Detection: Identifies implementation-coupled, tautological, and horizontally-sliced tests, with mocking guidelines restricted to system boundaries. - Use Case: When building a new checkout feature, use this Skill to agree on the public seams, write one failing behavior test, implement the minimal code to pass it, and repeat until the feature is complete. ## Quick Start Ask the assistant to build the next feature test-first using the tdd skill, starting by agreeing on the public seams to 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 against a public interface first, then write only enough code to make it pass. Repeat one vertical slice at a time, and leave refactoring to the review stage rather than the 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 agreed with the user before writing any test, never against private methods or internal collaborators.

When should I mock dependencies 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 with SDK-style interfaces for mockability.

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 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 the expected value the same way the code does, so it passes by construction. Avoid it by deriving expected values from independent sources like known literals, worked examples, or the specification.