tdd-workflow

Guides test-driven development using Red-Green-Refactor cycles and behavior-focused test design.

Updated Apr 13, 2026
One-click install
npx skills add https://github.com/JenilRevaliya/ARGUS --skill tdd-workflow-jenilrevaliya
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd-workflow
Source: https://github.com/JenilRevaliya/ARGUS/tree/main/.agent/skills/tdd-workflow
Command: npx skills add https://github.com/JenilRevaliya/ARGUS --skill tdd-workflow-jenilrevaliya

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after implementation often leads to fragile tests that verify internal details instead of behavior, and skipping disciplined cycles produces untested or over-engineered code. This Skill enforces a strict Test-Driven Development workflow so tests drive design and refactoring stays safe. ## Core Features & Use Cases - Red-Green-Refactor Discipline: Enforces writing a failing test first, implementing the minimum code to pass, then refactoring only after green. - Test Double Guidance: Clarifies when to use dummies, stubs, spies, and mocks, with a rule to mock only at architectural boundaries like databases and networks. - Behavior Over Implementation: Prevents test-induced design damage by testing public API contracts instead of private internal state. - Use Case: When building a pricing module with discount rules, write the failing test for the desired API first, implement the minimal logic, then refactor constants and structure with tests guaranteeing behavior. ## Quick Start Use the tdd-workflow skill to build a discount calculation function using strict Red-Green-Refactor cycles.

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 with Red-Green-Refactor?▼

Write a failing test that describes the desired API behavior first (Red), then write the minimum code to make it pass (Green), and only then refactor the implementation while keeping tests green. Never write implementation before the failing test.

When should I use mocks vs stubs vs spies in unit tests?▼

Use stubs to hardcode responses, spies to verify call counts, and mocks to assert exact call payloads. Only apply them at architectural boundaries like databases, networks, or filesystems, never for internal business logic.

Why is testing implementation details a bad practice?▼

Testing internal state or private methods makes tests fragile, breaking whenever code is refactored or renamed. Test the public behavior contract instead, such as verifying getBalance() output rather than inspecting a private balance variable.

What happens if my test passes before I write the code?▼

A test that passes before implementation tests nothing and is useless. The Red phase is mandatory: the test must fail first to prove it actually exercises the new behavior you are about to build.

When should I not use TDD?▼

TDD adds the most value for complex algorithms, deep business logic, and regulated systems. For trivial throwaway scripts or exploratory prototypes, the strict cycle overhead may outweigh its benefits.