tdd-workflow

Guides test-driven development through the red-green-refactor cycle with naming and commit conventions.

Updated Sep 10, 2026
One-click install
npx skills add https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula --skill tdd-workflow-serpro-workshop-fortaleza
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd-workflow
Source: https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula/tree/main/.github/skills/tdd-workflow
Command: npx skills add https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula --skill tdd-workflow-serpro-workshop-fortaleza

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing code before tests leads to untested behavior, brittle designs, and regressions. This Skill enforces disciplined test-driven development so every behavior change starts with a failing test and ends with a refactoring pass. ## Core Features & Use Cases - Red-Green-Refactor Cycle: Enforces one failing test at a time, minimal code to pass, and mandatory refactoring while tests stay green. - Test Design Guidance: Provides rules for naming tests after behavior, using Given-When-Then structure, and choosing the next test from simplest non-trivial cases. - Design Feedback Diagnosis: Maps TDD friction (hard construction, excessive mocking) to underlying design problems like SRP violations and hidden coupling. - Use Case: When fixing a bug in unfamiliar Java code, use this Skill to write a failing test reproducing the bug, make it pass with minimal change, then refactor, committing at each green step with REQ-ID traceability. ## Quick Start Use the tdd-workflow skill to guide me through writing a failing test first for the new tax calculation behavior, then making it pass and refactoring.

Frequently Asked Questions about tdd-workflow

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

FAQPage Schema
How do I practice test-driven development with the red-green-refactor cycle?

Write the smallest failing test expressing the next behavior (red), write the minimal code to make it pass (green), then improve the design while tests stay green (refactor). Commit at each green step and cover one behavior per cycle.

How do I choose which test to write next in TDD?

Start with the simplest non-trivial case, such as the happy path with one input. Then add a single variation like a boundary, branch, or error. Avoid writing one large test covering everything at once.

When should I use mocks or test doubles in TDD?

Use a test double only when the real collaborator is slow, nondeterministic, or does not exist yet. Never mock types you do not own; wrap them in a thin abstraction first. A test that mocks everything tests nothing.

Why is TDD hard to apply to my code?

Difficulty usually signals design problems: hard-to-construct objects indicate too many collaborators, unreadable assertions suggest Law of Demeter violations, and heavy mocking reveals hidden coupling requiring a new abstraction.

What are common TDD antipatterns to avoid?

Avoid writing code before tests, skipping the refactor phase, tests duplicating implementation details, large shared test fixtures, and asserting on private methods or exact SQL strings. These produce fragile change-detector tests.