test-driven-development · Test-Driven Development
Implementing a feature or fixing a bug starts with a test: watch it fail, write the minimal code to pass, then refactor.
The iron law: no production code without a failing test first — code written before the test gets deleted and rewritten. Red (write a failing test) → verify red (correct failure reason) → green (minimal implementation) → verify green (full suite passes) → refactor. Exceptions (throwaway prototypes, generated code, config files) need the human partner's approval first.
Example invocation: "Implement this retry logic with TDD."
Full brief
Positioning
test-driven-development is a strict development discipline: write the test first, watch it fail, then write minimal code to pass. It governs the order of writing code — not a testing tutorial.
Core capabilities
- Iron law: no production code without a failing test first; code written ahead gets deleted and rewritten.
- Red-green-refactor loop: red (write failing test) → verify red (failure reason is the missing feature, not a typo) → green (minimal implementation) → verify green (current test + full project suite pass) → refactor (staying green).
- Good-test bar: one behavior per test (an "and" in the name means split it), names describe behavior, tests real code — not mocks.
- Minimal implementation: only what the test needs; no extra features, no refactoring other code, no "while I'm at it" improvements.
- Bug fixes: write a failing test reproducing the bug first, then follow the TDD cycle — the test becomes the regression guard.
- Excuse rebuttals: "too simple to test", "tests after are the same", "I manually tested", "deleting is wasteful" — all rebutted with reasons.
- Red flags: code before test, test passing immediately, can't explain the failure, tests "added later", "just this once" — any of these means delete and restart.
Workflow
- Write one minimal test describing the expected behavior
- Run it; confirm it fails (fails, not errors; failure reason as expected)
- Write minimal code to make it pass
- Run the current test + the full project suite; confirm all green, output clean
- Refactor (dedupe, rename, extract), staying green
- Next test; repeat the loop
Inputs & outputs
| Input | Required | Notes |
|---|---|---|
| Feature requirement / bug | Yes | The feature to build or the bug to fix |
Output: test-first code + an all-green test suite.
Fit
- New feature implementation
- Bug fixes
- Refactoring
- Behavior changes
Before you start
- No API key; needs a runnable test framework in the project.
- Exceptions need human-partner approval: throwaway prototypes, generated code, config files.
- Acceptance checklist: every new function has a test; watched each test fail; failure reasons as expected; minimal implementation; full suite green; clean output.
test-driven-development is part of the Aiglade Skill library. Invoke it from the Aiglade chat box in plain language.