tdd-workflow

Guides test-driven development using the RED-GREEN-REFACTOR cycle and AAA test pattern.

2|Updated May 30, 2026
One-click install
npx skills add https://github.com/virahitvin8/crafty-gis --skill tdd-workflow-virahitvin8
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd-workflow
Source: https://github.com/virahitvin8/crafty-gis/tree/main/GIT_STAR/.agent/skills/tdd-workflow
Command: npx skills add https://github.com/virahitvin8/crafty-gis --skill tdd-workflow-virahitvin8

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing code before tests often leads to untested edge cases, over-engineered implementations, and regressions. This Skill enforces a disciplined Test-Driven Development workflow so tests define the specification before any production code exists. ## Core Features & Use Cases - RED-GREEN-REFACTOR Cycle: Structured guidance for writing a failing test first, implementing the minimum code to pass, then refactoring safely. - Three Laws of TDD: Rules that constrain how much test and production code you write at each step. - AAA Pattern & Prioritization: Arrange-Act-Assert test structure plus a priority order covering happy paths, error cases, and edge cases. - Use Case: When fixing a bug, write a failing test that reproduces it first, then implement the minimal fix and refactor while keeping all tests green. ## Quick Start Use the tdd-workflow skill to help me build a new input validation function by writing failing tests first, then the minimal implementation, then refactoring.

Frequently Asked Questions about tdd-workflow

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

FAQPage Schema
How do I start test-driven development on a new feature?

Begin with the RED phase: write a failing test that describes the expected behavior, such as "should handle empty input". Then write the minimum code to make it pass, and refactor only after all tests are green.

What is the RED-GREEN-REFACTOR cycle in TDD?

RED means writing a failing test first, GREEN means writing the simplest code to make it pass, and REFACTOR means improving naming, structure, and duplication while keeping all tests passing. The cycle repeats for each new behavior.

When should I not use TDD?

TDD has low value for exploratory spikes and UI layout work where requirements are unclear. In those cases, prototype first to understand the problem, then apply TDD once the behavior is well defined.

How many assertions should a single test have?

Ideally one assertion per test, so each test verifies a single behavior. Multiple assertions make failures harder to diagnose and blur the specification the test is meant to express.

Why must the test fail before writing implementation code?

Watching the test fail confirms it actually exercises the intended behavior and is not a false positive. Skipping the RED phase risks writing tests that pass trivially and provide no real specification.