mcpField
T
tdd-workflow

tdd-workflow

github.com/composio-communityTesting & quality1463 installsUpdated 24w ago
Repository

About tdd-workflow

A methodology skill for developers who want to apply test-driven development to behavior that can be expressed with assertions. It enforces a one-test-at-a-time red, green, refactor loop, including a full test-suite run and failing-first regression tests for bugs.

Key features

  1. 01One failing test per cycle
  2. 02Minimum implementation to pass
  3. 03Full-suite checks after changes
  4. 04Refactoring under a green test suite
  5. 05Failing-first bug regression tests

Use cases

  1. 01Implementing business logic or algorithms
  2. 02Testing parser and API behavior
  3. 03Fixing bugs with regression coverage

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/composio-community/opencode-skills --skill tdd-workflow

After installing, type/tdd-workflowin Claude Code to confirm it loaded.

Details

From the project README

TDD Workflow

A disciplined red → green → refactor loop. One failing test at a time, the minimum code to pass, then refactor under a green bar. This is a methodology skill — follow the loop exactly; do not batch.

When to use

Use when behavior can be expressed as assertions: business logic, parsers, APIs, algorithms, bug fixes (reproduce as a failing test first). Skip for throwaway spikes, pure UI layout, or exploratory prototypes with no maintenance horizon.

The loop

RED — write one failing test
  • Pick the smallest unspecified behavior.
  • Write one test asserting it. Run it. Confirm it fails for the right reason (assertion failure, not import/syntax error).
  • A test that passes immediately, or fails on a typo, is not a red. Fix and re-run.
GREEN — minimum code to pass
  • Write the least code that makes that test pass — hardcoding is acceptable here.
  • Run the full test suite, not just the new test. Green means all pass.
  • Do not add untested code "while you're there." If you want it, it needs a test → back to RED.
REFACTOR — improve under green
  • Remove duplication, clarify names, simplify structure.
  • Re-run the full suite after each change. Any red → revert the refactor, don't debug forward.
  • No behavior change here. New behavior is a new RED.

Repeat until the feature's behaviors are all covered.

Setup

Detect the project's existing runner — do not introduce a new one.

# JS/TS:  npx vitest run   |  npx jest
# Python: pytest -q
# Go:     go test ./...
# Rust:   cargo test

If no framework exists, ask which to add before starting; match the ecosystem default.

Bug-fix mode

  1. RED: write a test that reproduces the bug and fails.
  2. GREEN: fix until it passes and nothing else breaks.
  3. The reproduction test stays as a regression guard.

Never fix a bug without a failing test that proves it existed.

Test quality

  • One behavior per test; the name states the behavior.
  • Assert observable outcomes, not internal calls, unless the interaction is the contract.
  • Cover edge cases as their own REDs: empty, boundary, invalid input, async failure, concurrency.
  • A test you can't make fail by breaking the code tests nothing — delete or fix it.

Anti-patterns

  • Writing implementation first, then tests to match it (that's not TDD).
  • Writing 10 tests then implementing — you lose the design feedback.
  • Skipping the "confirm it fails" step.
  • Refactoring and adding behavior in the same step.
  • Mocking so heavily the test passes even when the real code is broken.

Done when

All behaviors have failing-first tests that now pass, full suite is green, no untested production code, and the bug-fix tests are retained as regression coverage.

Comments

Markdown supported