tdd

Guides test-first feature development and bug fixes using the red-green-refactor loop.

2|2|Updated Jun 28, 2015
One-click install
npx skills add https://github.com/camercu/dotfiles --skill tdd-camercu
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/camercu/dotfiles/tree/main/common/.config/agents/skills/tdd
Command: npx skills add https://github.com/camercu/dotfiles --skill tdd-camercu

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? It enforces disciplined test-driven development so features and bug fixes are built test-first, preventing untested production code, brittle implementation-coupled tests, and regressions. ## Core Features & Use Cases - Double-Loop Workflow: Outer failing acceptance test (GIVEN-WHEN-THEN) drives an inner red-green-refactor unit test loop until the feature passes. - Testing Without Mocks: Applies James Shore's nullable patterns, configurable responses, and output tracking so tests stay state-based and fast without mock frameworks. - Design Guidance: Reference docs cover deep modules, interface design for testability, tracer bullets, and Fowler's refactoring smell catalog. - Use Case: When asked to add a discount feature, write one failing acceptance test through the public API, then drive the implementation with one unit test at a time until acceptance passes. ## Quick Start Use the tdd skill to build this feature test-first with a failing acceptance test and a red-green-refactor loop.

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 on a new feature?▼

Start with one failing acceptance test written as GIVEN-WHEN-THEN through the public interface, then run an inner loop of one failing unit test, minimal code to pass, and refactor. Repeat until the acceptance test passes, then audit coverage.

How to write unit tests without mock frameworks?▼

Use nullable infrastructure: give wrappers create() and create_null() factories, configure responses in domain terms, and track output as domain events instead of verifying calls. Reserve mocks for cases where call ordering itself is the behavior under test.

Should tests verify through public interfaces or internal state?▼

Tests should verify behavior through public interfaces only, never by reading databases or internals directly. If verification through the interface is impossible, the interface is incomplete and needs a query method or output tracking.

When should I not write all tests up front?▼

Never write all tests up front; bulk tests test imagined behavior rather than real design. Write one test, implement minimally, then pick the next test using ZOMBIES (Zero, One, Many, Boundaries, Interfaces, Exceptions, Simplify).

Why does a bug fix need a failing test first?▼

The Prove-It rule requires a failing reproduction test before any bug fix so the fix is verified and regression-proofed. A passing reproduction test afterward confirms the bug is actually fixed rather than assumed fixed.