Reproduce First: Expected vs Actual

Why this matters

"The form sometimes breaks" cannot be fixed, because nobody knows what "it" is. Every guess-and-fix cycle on a phantom costs a change that may add new faults. A reproduction converts mood into mechanism: steps that trigger it every time, expected versus actual stated plainly. Half of all debugging is this step; the fix is often obvious once the scene is stable.

Concepts

The reproduction has three lines. Expected ("submit shows my values back"), actual ("submit shows nothing"), steps ("fill name only, leave time empty, submit"). Write it before touching code or asking the tool. If the steps trigger it every time, the bug is caged: any fix can be proven by running the same steps.

Halving the suspect area. When the fault's home is unknown, remove half the suspects and re-run: disable half the script, hide half the markup, submit with half the fields. The bug's presence or absence after halving tells you which half holds it. Repeat until one file, one function, one line remains. Lesson M03L12's addresses are the endpoint; halving is the road.

Intermittent bugs. Sometimes-triggered means a hidden input varies: timing, stored data, field order, quota state. Hunt by varying one condition at a time and logging which runs fail. Never "fix" an unreproduced bug with a rewrite; rewrites on phantoms trade one mystery for three.

Worked example

Report: "orders vanish sometimes." Reproduction attempt: submit three orders, reload, all stand. Vary: submit, delete one, reload: survivors stand. Vary again: submit with browser storage full of old course data: new entries missing. Caged: save fails silently when storage is full. Expected (entries persist), actual (entries dropped without a message), steps (fill storage, submit, reload). The fix (quota check plus a message) is now one change with a proof run attached.

Expected result: every bug you touch caged in three lines before any fix or tool message.

The common wrong move

Fix-first debugging: changing code while the bug still comes and goes, then declaring victory because it did not appear twice. Absence without reproduction proves nothing; the bug is waiting, not gone.

Lab and next step

The debugging lab cages three reported bugs into reproductions. Next, the following lesson writes the report that gets help: logs plus last change.