Reduce to a minimal case

A bug inside a full application hides behind hundreds of moving parts. A smaller failing case exposes the responsible boundary and makes experiments faster. Every component you remove is a component you no longer have to suspect.

The method: remove one dimension while preserving the bug. If the bug survives the cut, the removed part was innocent. If the bug disappears, you just found where it lives.

Reduce an application request:

full page -> one API call
one API call -> one input payload
production database -> disposable fixture
framework route -> direct function call

After every reduction, rerun the same assertion. The assertion is your anchor — “the total comes back as NaN” — and it must stay identical while everything around it shrinks.

A worked reduction

Say the checkout page shows NaN as the total. Start wide, then cut:

// step 1: call the API directly — still NaN, frontend is innocent
// step 2: call the function directly with the request payload
import { total } from './cart.mjs'

console.log(total([
  { name: 'notebook', price: 4.5 },
  { name: 'pen', price: undefined },
]))
// NaN

Two cuts, and the bug is one function plus one small payload. Keep cutting the payload. Remove the notebook line: the bug survives. Remove the pen line instead: the bug disappears. The minimal case is a single item with price: undefined, and the question has become sharp: why does that item exist in the cart data at all?

Stop removing when the behavior disappears, then compare the last two cases. The difference between the smallest case that fails and the largest case that passes is usually one line, and that line names the cause.

What not to minimize with

Do not minimize against live customer data. Copy only the smallest sanitized shape needed — above, two fake items reproduce what a real 40-item cart did. The minimal case also becomes your regression test input later, so it needs to be shareable and free of anything private.