test-driven-development

Enforces red-green-refactor test-driven development workflow before writing implementation code.

1|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/D1ssolve/craft-agents --skill test-driven-development-d1ssolve
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/D1ssolve/craft-agents/tree/main/skills/test-driven-development
Command: npx skills add https://github.com/D1ssolve/craft-agents --skill test-driven-development-d1ssolve

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Developers often write production code first and add tests afterward, which produces tests that may pass for the wrong reasons or fail to verify actual behavior. This Skill enforces a strict test-first discipline so every feature and bugfix is backed by a test that was watched failing before implementation. ## Core Features & Use Cases - Red-Green-Refactor Cycle: Guides writing one minimal failing test, verifying the failure, implementing the simplest passing code, then refactoring while keeping tests green. - Failure Verification Gates: Mandates watching each test fail for the expected reason (missing feature, not typos) before any production code is written. - Completion Checklist: Provides a verification checklist covering test coverage, minimal implementation, pristine output, and edge cases. - Use Case: When implementing a retry mechanism, write a test asserting the operation retries three times, watch it fail, implement the minimal retry logic, confirm all tests pass, then refactor. ## Quick Start Use the test-driven-development skill to implement this feature by writing a failing test first, then the minimal code to make it pass.

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 new feature?

Write one minimal test describing the desired behavior, run it and watch it fail for the expected reason, then write the simplest code that makes it pass. After green, refactor to remove duplication while keeping all tests passing.

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

Red means writing a failing test for one behavior, green means writing the minimal code to pass it, and refactor means cleaning up names and duplication without adding behavior. Each phase is verified by running the test suite.

Why must I watch the test fail before writing code?

Watching the test fail proves it actually tests the missing behavior rather than passing accidentally or testing existing functionality. A test that passes immediately means you are testing existing behavior and the test must be fixed.

What should I do if I already wrote code before the test?

Delete the production code and start over with a failing test first. Code written before its test violates the core TDD rule, and keeping it means you cannot verify the test fails for the right reason.

When should mocks be used in TDD tests?

Mocks should be avoided unless unavoidable; tests should use real code so they demonstrate actual behavior. Prefer concrete implementations and reserve mocks for external boundaries that cannot run in the test environment.