tdd-workflow

Name: tdd-workflow
Availability: InStock
Author: bennybennison

Guides iterative red-green-refactor cycles for test-driven application development.

Updated Apr 11, 2026

Search Tags:#tdd #refactor #coverage #unit-testing #test-organization #test-driven-development

Ready to run

npx skills add https://github.com/bennybennison/agent-toolkit --skill tdd-workflow-bennybennison

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: tdd-workflow
Source: https://github.com/bennybennison/agent-toolkit/tree/main/skills/tdd-workflow
Command: npx skills add https://github.com/bennybennison/agent-toolkit --skill tdd-workflow-bennybennison

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

TDD Workflow codifies a disciplined cycle to prevent regressions and ensure new behaviour is specified by tests before production code is written, reducing bugs and design drift.

Core Features & Use Cases

Red-Green-Refactor cycle: Write a failing test, implement the minimal code to pass, then refactor while keeping tests green.
Cycle sizing and pace: Emphasizes small 2–10 minute cycles to keep feedback fast and development focused.
Coverage strategy: Prioritizes near-100% domain logic unit tests, high coverage for use cases with mocked ports, and integration tests for adapters.
Use cases: Feature development, reproducing and fixing bugs with regression tests, and specifying complex business logic through executable tests.

Quick Start

Write a single failing test that describes the next behaviour, run it to confirm failure, implement the minimum code to make it pass, then refactor with tests green.

Frequently Asked Questions about tdd-workflow

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

FAQPage Schema

How do I use test-driven development to prevent regressions in application code?▼

Test-driven development prevents regressions by codifying a disciplined red-green-refactor cycle to ensure new behaviour is specified by tests before production code is written. This reduces bugs and design drift across feature development and complex business logic.

What is the best way to structure unit tests for complex business logic?▼

The best way to structure unit tests for complex business logic is by prioritizing near-100% coverage for domain logic while mocking external ports. This focuses testing on behaviour rather than implementation, ensuring executable tests validate requirements accurately.

How do I apply the red-green-refactor cycle when fixing bugs?▼

To apply the red-green-refactor cycle when fixing bugs, reproduce the bug with a failing regression test, implement the minimal code to make it pass, and then refactor while keeping tests green. Emphasize small 2–10 minute cycles to keep feedback fast.

Does test-driven development require integration tests for external adapters?▼

Test-driven development requires integration tests for external adapters to verify interactions with external ports. While domain logic achieves near-100% unit test coverage with mocked ports, adapter integration tests ensure the complete system functions correctly.

Why does my test-driven development cycle feel slow and unfocused?▼

Your test-driven development cycle feels slow because cycles are too large. Emphasize small 2–10 minute cycles to keep feedback fast and development focused, writing a single failing test for the next behaviour, implementing minimal code, and refactoring with tests green.

Can I use TDD to specify complex business logic through executable tests?▼

You can use TDD to specify complex business logic through executable tests by writing failing tests that describe the next behaviour and validating requirements before implementation. This iteratively drives out domain logic while maintaining high test coverage.