Refactoring Without Tests

1. 1
   1. Observe

   Run it against a copy of real data and record everything it produces: invoice rows, table writes, outbound email. No code changes at all.

   fails by A baseline recorded from an unrepresentative period, so the annual-billing customers are absent and the suite is green on cases that never occur in it.

2. 2
   2. Provably-safe moves only

   Tooling-performed renames, extractions with no control-flow change, a parameter introduced with a default equal to the current value. Nothing that requires judgement.

   fails by "While I am here." One unverified judgement call hidden inside 200 lines of mechanical diff, at the point of maximum risk (Review Size).

3. 3
   3. Open a seam

   Make the clock, the payment API, the mailer and the database substitutable — a field with a real default, injected only in tests (Seams).

   fails by Opening the seam too deep, so the test exercises a fragment rather than the behaviour that matters (What a Unit Is).

4. 4
   4. One characterization test

   Run the routine with the world substituted, capture the output, diff against the step-1 baseline. The circle is now broken.

   fails by Nondeterminism — a timestamp or a generated id in the output — so the first diff is noise and everyone loses faith in the approach (A Deterministic Core).

5. 5
   5. Widen, but only where it matters

   Add cases covering the paths your change can affect, drawn from real data. Adding the second test is cheap now.

   fails by Trying to characterize all 700 lines, which spends the budget on code carrying no risk in this change.

6. 6
   6. Refactor with the net

   The ordinary loop, small steps, verify each one (The Refactoring Loop).

   fails by Going straight to the behaviour change and skipping the restructuring that would have made it four lines.

7. 7
   7. Change behaviour, last and alone

   One commit, its own test, and a deliberate reading of every characterization diff it produces.

   fails by Updating the failing characterization tests to match the new output without reading them — which converts the change detector into a rubber stamp (Characterization Tests).

If the deadline does not allow steps one to six, the honest fallback is a contained new branch for the new payment term that leaves the existing path byte-for-byte untouched, plus a written debt record saying what was skipped and what would trigger doing it properly (The Debt Register).

1// before — untestable: real clock, real API, real mailer
2function runMonthlyInvoicing(customers: Customer[]) {
3  const now = new Date()
4  ...
5  await paymentApi.charge(inv.total, c.cardToken)
6  await mailer.send(c.email, render(inv))
7}
8 
9// after — same behaviour, same call sites, testable
10interface World {
11  now(): Date
12  charge(amount: Money, token: string): Promise<ChargeResult>
13  send(to: string, body: string): Promise<void>
14}
15 
16const PRODUCTION: World = {
17  now: () => new Date(),
18  charge: (a, t) => paymentApi.charge(a, t),
19  send: (to, b) => mailer.send(to, b),
20}
21 
22function runMonthlyInvoicing(
23  customers: Customer[],
24  world: World = PRODUCTION,   // default preserves behaviour
25) { ... }

The default argument is what makes this safe: every existing caller compiles and behaves identically, so the change is verified by the type checker rather than by a test that does not exist yet. World is deliberately one crude interface rather than three well-designed dependencies — splitting it properly is a later step, done with the net in place. Doing the good design now would be the judgement call this step is not allowed to make.

The contained state is a legitimate terminal state, not a failure — the failure is reaching it without writing down what was skipped. What makes it acceptable is that the existing path is untouched, so the blast radius of the new payment term is exactly the new payment term.