test-driven-development

Guides test-first development using the red-green-refactor cycle for code changes and bug fixes.

1|Updated May 29, 2026
One-click install
npx skills add https://github.com/memasanz/agent-harness --skill test-driven-development-memasanz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/memasanz/agent-harness/tree/main/.github/skills/test-driven-development
Command: npx skills add https://github.com/memasanz/agent-harness --skill test-driven-development-memasanz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes and bug fixes often ship without proof they work, leading to regressions and untested behavior. This Skill enforces a test-first workflow where every behavior change is verified by a failing test before implementation begins. ## Core Features & Use Cases - Red-Green-Refactor Cycle: Write a failing test first, implement minimal code to pass it, then refactor with tests as a safety net. - Prove-It Pattern for Bug Fixes: Reproduce any reported bug with a failing test before attempting a fix, creating a permanent regression guard. - Test Pyramid and Sizing Guidance: Allocate effort across unit, integration, and E2E tests, and classify tests by resource consumption (small, medium, large). - Use Case: A bug report says completing a task does not set its timestamp. Write a reproduction test that fails, implement the fix, and confirm the test passes with no regressions. ## Quick Start Ask the agent to implement a new feature or fix a bug using test-driven development, starting with a failing test that proves the expected behavior.

Frequently Asked Questions about test-driven-development

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

FAQPage Schema
How do I practice test-driven development when fixing a bug?

Write a test that reproduces the bug first and confirm it fails, then implement the fix and verify the test passes. This Prove-It Pattern creates a permanent regression guard so the bug cannot silently return.

How should I split tests between unit, integration, and E2E?

Follow the test pyramid: roughly 80% unit tests for pure logic, 15% integration tests for API and database boundaries, and 5% E2E tests reserved for critical user flows. Unit tests run in milliseconds and should dominate the suite.

When should I use mocks instead of real implementations in tests?

Prefer real implementations first, then fakes, stubs, and mocks last. Mock only when the real dependency is too slow, non-deterministic, or has uncontrollable side effects like external APIs or email sending.

When is test-driven development not appropriate?

Skip TDD for pure configuration changes, documentation updates, and static content changes with no behavioral impact. Any change that alters logic or behavior should have a corresponding test.

Why do my tests break every time I refactor code?

Tests that verify internal method calls or implementation details break during refactoring even when behavior is unchanged. Assert on inputs and outputs (state-based testing) instead of interaction sequences.