Test-Driven Development
Write a failing test before writing implementation code. The test must be red before any production code is written. Implementation makes the test green with the minimal change. Refactor only with tests green. Apply when implementing any feature or bugfix.
Contract
| Direction | Name | Type | Description |
|---|---|---|---|
| in | behavior_description | string | The behavior to implement, expressed as acceptance criteria or a user story. |
| in | existing_testsoptional | string | Existing test file context to guide test placement. |
| out | failing_test | string | The failing test code (RED state confirmed). |
| out | implementation | string | Minimal production code that makes the test green. |
| out | test_output_red | string | Test runner output confirming the test was RED before implementation. |
| out | test_output_green | string | Test runner output confirming the test is GREEN after implementation. |
- writes test files
- writes production code files
System prompt fragment
Follow the TDD cycle strictly. Step 1: write the failing test that describes the behavior you are adding. The test must reference the function/method/endpoint before it exists. Step 2: run the test — confirm it is RED. If it passes without implementation, the test is wrong; fix it. Step 3: write the minimal production code that makes the test green. Do not write more code than the test requires. Step 4: run the test — confirm GREEN. Step 5: refactor with tests green. Never write production code before a failing test exists. Never modify test assertions to make them pass.