Test-Driven Iteration
Claude CodeDefinition
A Claude Code workflow where tests are written or identified before implementation, and each iteration is verified by running the test suite. Claude uses test failures as feedback to correct its approach. The 'interview pattern' involves asking clarifying questions before writing any code.
Example Usage
Instruct Claude to write failing tests first, then implement code to pass them — failing tests provide clearer correction signals than vague feedback.
In Depth
Test-driven iteration is a Claude Code workflow that uses an existing or purpose-written test suite as the objective feedback signal driving each implementation cycle. The sequence is: write (or identify) failing tests that precisely describe desired behavior → instruct Claude to implement code that makes them pass → run the suite → if tests fail, feed the failure output back to Claude as the next prompt → repeat until green.
The critical difference from ordinary test-driven development (TDD) is that the agent, not the developer, is running the loop. Claude reads the test failures, reasons about what they imply, revises the implementation, and re-runs — autonomously iterating until the suite passes or it determines it is stuck and needs human input. The developer's job shifts from writing implementation details to writing precise tests and reviewing the final diff.
Failure output is a higher-quality correction signal than natural language feedback. "The test test_empty_input_returns_400 failed with AssertionError: 200 != 400" tells Claude exactly what is wrong and where. Contrast this with vague feedback like "that doesn't seem right" — which forces Claude to guess at the failure mode.
The interview pattern is a named variant: before writing any code, Claude asks clarifying questions about edge cases, error conditions, and constraints. The answers are encoded directly into tests, so the test suite becomes the living specification. This is especially valuable when requirements are underspecified — the interview externalizes assumptions before they become silent bugs.
Test-driven iteration pairs naturally with the Stop hook: you configure a Stop lifecycle hook that runs the test suite whenever Claude signals it is done. If tests fail, the hook can prevent the session from closing and re-prompt with the failure output, creating a fully autonomous quality gate without any developer interaction between cycles. This is the integration the CCA-F exam most frequently tests.
See the Test-Driven Iteration concept page for a full worked example of the Stop hook integration pattern and the interview pattern in practice.
The iterative-refinement glossary entry describes the broader workflow family; test-driven iteration is its most rigorous specialization, trading flexibility for objective correctness signals.
How It's Tested & Common Confusions
Scenario question: A team wants Claude to autonomously fix failing CI tests without human intervention between cycles. Which combination of Claude Code features enables this?
- Correct: Stop hook that runs the test suite and re-prompts Claude with failure output if any tests fail.
- Distractors: PreToolUse hook (fires before tools, not at session end); plan mode (read-only, not execution); PostToolUse hook (fires after each tool call, not at completion).
True/false pattern: "In test-driven iteration, the developer writes the tests and Claude writes the implementation, but Claude never runs the tests itself."
- Correct answer: False — Claude runs the test suite as part of its iteration loop and uses the failure output to self-correct.
Comparison question: When does the interview pattern apply?
- When requirements are underspecified and assumptions need to be encoded as tests before implementation begins.
Frequently Asked Questions
What makes test failure output a better correction signal than natural language feedback?
Test failures are unambiguous, machine-generated, and point to a specific assertion at a specific location. Claude can parse stack traces and assertion errors precisely, identifying the exact behavioral gap. Natural language feedback like "it's not quite right" provides no actionable anchor — Claude must hypothesize about what is wrong rather than read the evidence directly.
How does the Stop hook enable autonomous test-driven iteration?
The Stop hook fires whenever Claude signals it has finished a session. If you configure it to run the test suite and emit a non-zero exit code (or re-inject a failure prompt) when tests fail, Claude's session never actually closes until all tests pass. This creates a self-contained quality gate: write tests, kick off Claude, come back to a green suite — no manual intervention required in the middle of the loop.
Is test-driven iteration only for software development tasks?
No. Any task with a machine-checkable acceptance criterion can use this pattern. Data pipeline validation, API contract testing, linter rules, even structured-output schema validation all qualify. If you can write an automated check that returns pass or fail, you can build a test-driven iteration loop around it.