text
| 1 | # Loop — Per-Iteration Procedure |
| 2 | |
| 3 | Repeat this cycle up to `max_iterations` times, or until a stop condition in |
| 4 | `stop-conditions.md` is hit. |
| 5 | |
| 6 | ## 1. Select the next unit of behavior |
| 7 | |
| 8 | Within the current target module, pick one specific, nameable behavior that isn't |
| 9 | covered: a function, a branch (if/else path), an error case, or a boundary condition |
| 10 | (empty input, zero, max value, duplicate). Prefer, in order: |
| 11 | 1. Untested error paths and edge cases in code that *is* partially tested (these hide |
| 12 | the most real bugs). |
| 13 | 2. Fully untested public functions/methods. |
| 14 | 3. Untested branches within partially-tested functions. |
| 15 | |
| 16 | Avoid picking multiple unrelated behaviors in one iteration — one behavior per cycle |
| 17 | keeps the red/green signal clean. |
| 18 | |
| 19 | ## 2. Write the failing test (red) |
| 20 | |
| 21 | - Name the test after the behavior, not the implementation: |
| 22 | `"throws when quantity is negative"`, not `"test2"`. |
| 23 | - Assert on outcome (return value, thrown error, emitted event, persisted state), not |
| 24 | on internal implementation details that would make the test brittle to refactors. |
| 25 | - Run just this test (or the smallest relevant subset) and confirm it **fails**. If it |
| 26 | passes immediately, the test isn't exercising new behavior — revise it before |
| 27 | proceeding; a test that never fails is worse than no test. |
| 28 | - Confirm the failure reason matches expectations (e.g. "expected error, got |
| 29 | undefined" — not a typo or import error unrelated to the behavior under test). |
| 30 | |
| 31 | ## 3. Implement (green) |
| 32 | |
| 33 | - Write the minimum code needed to make the test pass. Resist adding unrelated |
| 34 | improvements in the same step — that's a separate change. |
| 35 | - Run the same test again and confirm it now passes. |
| 36 | |
| 37 | ## 4. Run the full suite |
| 38 | |
| 39 | - Run the complete test suite (not just the new test) to catch regressions. |
| 40 | - If something else broke, fix it before moving on — do not proceed to the next |
| 41 | iteration with a red suite. |
| 42 | |
| 43 | ## 5. Record the delta |
| 44 | |
| 45 | - Re-run the coverage tool (or estimate if per-iteration coverage runs are too slow — |
| 46 | in that case, run coverage every N iterations and note the cadence). |
| 47 | - Note: test added, coverage before → after for the targeted file, iteration count. |
| 48 | |
| 49 | ## 6. Decide: continue or stop |
| 50 | |
| 51 | Check `stop-conditions.md`. If none apply and `max_iterations` isn't reached, return to |
| 52 | step 1 and pick the next behavior. |
| 53 |