playbooks

home / skills / zpankz / mcp-skillset / test-driven-development

test-driven-development skill

/test-driven-development

This skill enforces test-driven development by writing failing tests first, then minimal code to satisfy them, ensuring correct behavior.

This is most likely a fork of the test-driven-development skill from ed3dai
npx playbooks add skill zpankz/mcp-skillset --skill test-driven-development

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
1.6 KB
---
name: test-driven-development
description: Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
---

# Test-Driven Development (TDD)

## Overview

Write the test first. Watch it fail. Write minimal code to pass.

**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.

**Violating the letter of the rules is violating the spirit of the rules.**

## When to Use

**Always:**

- New features
- Bug fixes
- Refactoring
- Behavior changes

**Exceptions (ask your human partner):**

- Throwaway prototypes
- Generated code
- Configuration files

Thinking "skip TDD just this once"? Stop. That's rationalization.

## The Iron Law

```
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
```

Write code before the test? Delete it. Start over.

**No exceptions:**

- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Delete means delete

Implement fresh from tests. Period.

## Progressive Loading

**L2 Content** (loaded when methodology details needed):
- See: [references/methodology.md](./references/methodology.md)
  - Red-Green-Refactor Cycle
  - Good Tests Principles
  - Why Order Matters
  - Common Rationalizations
  - Verification Checklist

**L3 Content** (loaded when advanced patterns needed):
- See: [references/anti-patterns.md](./references/anti-patterns.md)
  - Testing Mock Behavior
  - Test-Only Methods
  - Mocking Without Understanding
  - Incomplete Mocks
  - Integration Tests as Afterthought
  - Quick Reference Guide

Overview

This skill codifies a strict test-driven development (TDD) workflow for JavaScript work: write the test first, confirm it fails, implement the minimal code to make it pass, then refactor. It enforces the core principle that a test must fail before it can prove anything, preventing false confidence from prewritten implementation. Use this skill to keep behavior verification accurate and development focused on requirements.

How this skill works

Before adding or changing production code, author a failing automated test that expresses the desired behavior or bug fix. Run the test suite, observe the new test fail, then implement the smallest change needed to pass. Once green, clean up the code and tests while keeping behavior coverage intact. Repeat this Red-Green-Refactor cycle for every feature, bug fix, and refactor.

When to use it

  • Implementing new features to define expected behavior up front
  • Fixing bugs so the regression is captured and prevented
  • Refactoring code with safety nets to prevent regressions
  • Altering behavior or APIs to document intended changes
  • Avoid in throwaway prototypes, generated code, or simple config edits unless explicitly required

Best practices

  • Always write the test first and verify it fails before writing production code
  • Keep implementations minimal to satisfy the test, then refactor for clarity
  • Make tests explicit and focused on observable behavior, not implementation details
  • Avoid peeking at existing code; if you did, discard and start fresh from the test
  • Use descriptive test names and maintain a verification checklist for changes

Example use cases

  • Add a new API endpoint: write endpoint tests, watch them fail, implement minimal handler
  • Fix a bug reported by users: reproduce with a failing test, implement fix, ensure test stays green
  • Refactor a module: create behavior tests first, refactor internals with confidence
  • Improve edge-case handling: add targeted tests for edge inputs, then implement handling

FAQ

What if the test never fails?

If a test doesn't fail initially, it likely isn't exercising the intended behavior. Revisit the test to ensure it targets production code paths and that the test environment matches runtime conditions.

Is TDD required for quick prototypes?

Not always. For throwaway prototypes or experiments, TDD can slow iteration. Use judgment and switch to TDD when the prototype becomes production-bound.

How strict must I be about deleting prewritten code?

Strict. If production code exists before a failing test, it can mask issues. Delete or revert that code and start the test-first flow to preserve test validity.