tdd

Develops software via a TDD cycle of Red-Green-Refactor with behavior-focused tests.

Updated Mar 12, 2026
One-click install
npx skills add https://github.com/mpsuesser/workspace --skill tdd-mpsuesser
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/mpsuesser/workspace/tree/main/dotconfig/pi/agent/skills/.deprecated/tdd
Command: npx skills add https://github.com/mpsuesser/workspace --skill tdd-mpsuesser

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you avoid fragile, implementation-coupled tests by applying a disciplined test-driven development loop that keeps tests focused on user-visible behavior.

Core Features & Use Cases

  • Integration-style verification: Write tests that exercise public interfaces end-to-end so they survive refactors.
  • Tracer bullet workflow (vertical slicing): Move one behavior at a time (RED → GREEN → refactor) instead of bulk-writing tests first.
  • Mocking at system boundaries: Mock external collaborators only (APIs, databases, time/randomness, filesystem) to keep tests meaningful.
  • Refactor safely after passing: Identify duplication and shallow modules after the cycle completes, while ensuring behavior stays covered.

Use this when you want to build new features or fix bugs by designing behavior-driven tests, especially when you care about integration tests and maintaining test stability through refactors.

Quick Start

Apply the TDD red-green-refactor loop to implement one public behavior at a time, using integration-style tests and mocking only system boundaries.

Frequently Asked Questions about tdd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write integration tests that survive refactoring?

Integration tests survive refactoring by asserting behavior through public interfaces only and mocking external collaborators exclusively at system boundaries like APIs, databases, and filesystems to avoid implementation coupling.

What is the red-green-refactor workflow in test-driven development?

The red-green-refactor workflow in test-driven development involves writing a failing test for one behavior, writing minimal code to pass it, and then safely refactoring to remove duplication while maintaining test coverage.

How do I apply vertical slicing when building new features?

Vertical slicing in feature development moves one behavior at a time through the test-driven development loop, acting as tracer bullets to incrementally verify user-visible behavior rather than bulk-writing tests first.

Why do my unit tests break when I refactor internal code?

Unit tests break during refactoring when they are implementation-coupled rather than behavior-focused, which is resolved by applying test-driven development to write integration-style checks using public-interface-only assertions.

When should I use mocking in test-driven development?

Mocking in test-driven development should be restricted to system boundaries such as external APIs, databases, time, randomness, and the filesystem to keep tests meaningful and focused on user-visible behavior.

When should I identify refactor candidates during TDD?

Refactor candidates in TDD should be identified after the test passes during the refactor phase, allowing you to safely remove duplication and shallow modules while ensuring behavior stays covered.