A TDD increment now needs hundreds of lines to go green. How do you split it into smaller steps?

## Recognising the problem A test-driven increment is supposed to be a short round trip: one failing case, a small edit, green. When the edit needed to reach green becomes large, several things go wrong at once. The red bar stops being informative, because the case can fail for many independent reasons and the failure message names only the first. You lose the ability to attribute a change to an outcome, so the moment something breaks you reach for a debugger — at which point the test is no longer driving the design, it is a slow way of running the program. And the window during which you cannot safely restructure anything stretches from seconds to the length of the whole implementation. The named symptoms worth being able to state in an interview: the case's name contains "and"; the arrange section is longer than the code you are about to write; you cannot predict which assertion will fail first; you have been red for long enough to have forgotten your last edit. ## The decomposition method Treat the behaviour as a set of independent dimensions and drive one at a time. Take a subscription renewal job whose next increment is: *charge every due subscription in a batch, and if any charge fails, roll the whole batch back and report which one failed.* That is at least five dimensions — batch size, per-item success, the rollback, the report, and the ordering guarantee — and driving them together is the hundreds-of-lines increment. The sequence that keeps each step small: ```pseudocode # 1. Most degenerate input the behaviour admits test "an empty batch charges nothing and reports no failures" # 2. One item, happy path -- introduces the charge call, nothing else test "a batch of one due subscription charges 5300 cents once" # 3. One item, sad path -- introduces the failure outcome only test "a batch of one whose charge is declined reports that subscription" # 4. Two items -- introduces iteration, still no rollback test "a batch of two due subscriptions charges both" # 5. Two items, second fails -- now, and only now, rollback exists test "when the second of two charges is declined, the first is reversed" # 6. Ordering, reporting detail, partial-failure edge cases test "a declined charge in a batch of three reverses both earlier charges" ``` Three properties make this work. **Each step adds one reason for the code to change.** Step 4 introduces iteration and nothing else; if it goes red, iteration is the suspect. **Everything not yet driven may be degenerate.** After step 2 the code can charge exactly one item and know nothing about rollback; that is not an unfinished feature, it is a correct implementation of the cases that exist. **The steps compose forwards.** Step 5 does not invalidate step 3; it constrains a dimension step 3 left free. ## Other ways to shrink a step When a dimension itself is too large, further tools: - **Split the assertion.** A case that asserts on the charge, the reversal and the report at once is three cases wearing a trench coat. Assert one outcome per case while driving; the combined check, if you want it, is a later addition. - **Push the hard part behind a boundary.** Drive the orchestration against a collaborator role that does not exist yet, standing it in for now, and drive the real one separately. This changes the step from "implement the whole thing" to "implement the coordination". - **Take the degenerate case first.** Empty, zero, one, absent. These force the skeleton — the signature, the return shape, the error channel — with almost no logic, and everything afterwards is an extension rather than a start. - **Write the assertion you wish you could make, then reduce it.** If it is unwritable, the ambiguity is in the requirement, and no step size will rescue it. ## Knowing when to abandon the attempt Sometimes the decomposition is not visible from inside the red bar. The standard advice is unglamorous: return to the last state where everything was green, throw away the half-finished edit, and plan the sequence of cases before typing again. Practitioners find this hard because the discarded work feels expensive. It usually is not — the code you throw away is the code you did not understand, and you keep the understanding. What is genuinely expensive is a long red period ending in a debugging session. ## The cost argument Small steps look slower per step and are usually faster per feature, because the expensive part of development is not typing, it is locating the cause of a surprise. With a two-minute increment the search space for any new failure is one small edit. There is a second, longer-term effect: cases driven one dimension at a time tend to be narrow and independently meaningful, which is what keeps a large regression pack — say a 340-case suite — diagnosable, because one broken behaviour turns a handful of cases red rather than forty. Be careful how you claim this in an interview: the general defect-cost curve is often quoted with confident multipliers, and those specific numbers are contested. The defensible statement is about feedback locality — smaller steps mean a smaller suspect set — not about a numeric payback ratio.