tdd

Guides test-driven development using the red-green cycle with seam-based test placement.

2|Updated Jul 6, 2026
One-click install
npx skills add https://github.com/NAMEWTA/learning-open-code --skill tdd-namewta
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/NAMEWTA/learning-open-code/tree/main/translator/open-ai-skills/matt-pocock-skills/skills/engineering/tdd
Command: npx skills add https://github.com/NAMEWTA/learning-open-code --skill tdd-namewta

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests that survive refactoring is hard: tests coupled to implementation details break on every code change, tautological tests can never fail, and horizontal slicing locks in test structure before the implementation is understood. This Skill provides a reference guide for running the red-green TDD loop correctly so the resulting tests verify behavior through public interfaces. ## Core Features & Use Cases - Red-Green Loop Rules: Enforces writing a failing test first, then only the minimal code to pass, one vertical slice at a time. - Seam-Based Test Placement: Requires agreeing on public-interface seams with the user before writing any test, focusing effort on critical paths. - Anti-Pattern Detection: Identifies implementation-coupled tests, tautological assertions, and horizontal slicing, with good/bad examples in tests.md and mocking guidance in mocking.md. - Use Case: When fixing a bug in a checkout flow, write one failing test at the public checkout interface, implement the minimal fix, and repeat—mocking only the external payment API at the system boundary. ## Quick Start Ask the AI to build the next feature using test-driven development with the red-green cycle, agreeing on the test seams first.

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 cycle?

Write one failing test against a public interface first, then write only the minimal code needed to make it pass, and repeat one slice at a time. Do not predict future tests or add speculative functionality during the loop.

What makes a good unit test versus a bad test?

A good test verifies behavior through public interfaces and survives refactoring, reading like a specification of what the code does. Bad tests mock internal collaborators, test private methods, or assert call counts, breaking whenever internals change.

When should I use mocks in testing?

Mock only at system boundaries: external APIs, databases, time, randomness, and sometimes the file system. Never mock your own classes or internal collaborators, and prefer dependency injection plus SDK-style interfaces to make boundary mocking straightforward.

What is a tautological test and why is it a problem?

A tautological test computes its expected value the same way the implementation does, so it passes by construction and can never catch a bug. Expected values must come from an independent source such as known literals or hand-computed examples.

Should refactoring happen inside the TDD loop?

No. Refactoring belongs to the review phase, not the red-green implementation loop. Each cycle should contain one seam, one test, and one minimal implementation, with restructuring deferred to a separate code review step.