See It Run

Input → lookup → branch → mutation → output. State before and after with exactly what changed; the flowchart of an operation; debugging an implementation from expected state to the wrong assumption; and "why does this exist?" for every field and function.

Input → Lookup → Branch → Mutation → Output

▶ lab

Every call to addItem passes through the same five stops. Tracing one call by hand — what came in, what was looked up, which way it went, what was changed, what went back — is how you find out whether the function you wrote is the operation you meant.

Q · addItem runs and the tests pass. Can you say, for one specific call, what it read, which branch it took and which field it changed — and if not, what do you actually know about it?

Before, Operation, After — and Exactly What Changed

▶ lab

A state change you cannot describe as "this field went from this to that" is one you have not seen. Put the state before, the operation, and the state after side by side, and name every difference — there are usually fewer than you think, and occasionally one more.

Q · You know the cart went from one Laptop to two. Can you list every field that changed, every one that did not, and say which line of the operation is responsible for each — and what would you miss if you could not?

Draw the Branches Before You Trust Them

addItem has two decisions and three exits, and every one of them is a rule. A flowchart of one operation is a map of its branches — which is a list of the cases the tests need and a picture of which order the checks run in.

Q · How many ways can a call to addItem end, and which check decides each one — and can you draw that without reading the code line by line?

Expected, Actual, Which Operation, Which Branch, Which Assumption

▶ lab

A wrong cart is not "broken"; it is a specific expected state, a specific actual state, one operation that turned the first into the second, one branch inside it that ran when another should have, and one assumption that made you write it that way. Five questions, in that order, and the bug has nowhere to hide.

Q · The cart shows Laptop twice. You have one function on the screen. What are the five questions that take you from "it is wrong" to the line, and why does the order of them matter?

Why Does This Exist?

Every class, function and field in the cart answers three questions: why is it here, what problem does it solve, what breaks if it is removed. A line that cannot answer them is cargo — it came from somewhere, it might be load-bearing, and nobody can tell.

Q · Pick any line of addItem — the find, the catalog check, the quantity field. Why does it exist, what problem does it solve, and what exactly breaks if you delete it — and how would you find out if you could not answer?