test-driven-development

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

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/Avistian/nba --skill test-driven-development-avistian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/Avistian/nba/tree/main/.cursor/skills/test-driven-development
Command: npx skills add https://github.com/Avistian/nba --skill test-driven-development-avistian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code written without tests breaks silently during refactors, and bug fixes without reproduction tests often fail to address the real issue. This Skill enforces a disciplined test-first workflow so every behavior change is proven by a failing test before implementation begins. ## Core Features & Use Cases - Red-Green-Refactor Cycle: Write a failing test first, implement the minimal code to pass, 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, guaranteeing the fix actually works. - Testing Best Practices: Guidance on the test pyramid, DAMP vs DRY in tests, state-based assertions over mocks, and anti-patterns like testing mock behavior or adding test-only methods to production code. - Use Case: A bug report arrives saying completing a task doesn't set its timestamp. Write a failing test that asserts completedAt is set, watch it fail, 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, writing a failing test before any production code.

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 on a bug fix?▼

Write a test that reproduces the bug first and confirm it fails, then implement the fix and confirm the test passes. This Prove-It Pattern guarantees the fix addresses the real bug and creates a permanent regression guard.

What is the red-green-refactor cycle in TDD?▼

Red means writing a failing test that defines the desired behavior. Green means writing the minimal code to make it pass. Refactor means cleaning up the implementation while keeping all tests green, then repeating the cycle.

Should I use mocks or real implementations in unit tests?▼

Prefer real implementations first, then fakes, stubs, and mocks last. Mock only when the real dependency is slow, non-deterministic, or has uncontrollable side effects like external APIs, since over-mocking produces tests that pass while production breaks.

When should I not use test-driven development?▼

Skip TDD for pure configuration changes, documentation updates, and static content edits with no behavioral impact. Any change that alters logic or could break existing behavior should go through the test-first cycle.

Why do my tests break every time I refactor code?▼

Tests that assert on 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 so refactors stay safe.