When reviewing a machine-drafted service case, how do you judge whether its setup and assumed data are honest?

juniorshould knowfreq 40%

answer

What does the case need before acting?
Find the line that created each fact
Borrowed data fails where it is absent
Guard the precondition before the action

basics

~20 s

Trace every fact the case depends on back to a line that created it. Anything it reads but never creates is a borrowed assumption that will fail wherever that data is absent, for reasons unrelated to the behaviour.

solid answer

~50 s

A draft is generated from a session that ran in a world already full of data, and preconditions are not steps, so they never make it into the draft as lines. Review the setup by listing what the case needs before its first meaningful action and finding the line that produced each item. Watch for identifiers lifted from the drafting session, for phrases like the most recent record that hold only when the case runs alone, and for standing accounts the case mutates. Then ask two more things: does a wrong precondition fail immediately and name itself, and could the product's own paths have produced this starting condition at all? A setup written straight into the store can manufacture a combination the system can never reach, and the case then proves behaviour over a world that does not exist.

A draft is generated from a session that ran in a world already full of data, and preconditions are not steps, so they never make it into the draft as lines. Review the setup by listing what the case needs before its first meaningful action and finding the line that produced each item. Watch for identifiers lifted from the drafting session, for phrases like *the most recent record* that hold only when the case runs alone, and for standing accounts the case mutates. Then ask two more things: does a wrong precondition fail immediately and name itself, and could the product's own paths have produced this starting condition at all? A setup written straight into the store can manufacture a combination the system can never reach, and the case then proves behaviour over a world that does not exist.

code

pseudocode · 13 lines

pseudocode

# drafted setup: borrows a world that happened to exist
account = "ACCT-4471"                  # never created here
order   = latest_order_for(account)    # collides with any parallel run
cancel_order(order.id)
assert order_status(order.id) == "CANCELLED"

# reviewed setup: creates what it needs, guards it, owns it
account = create_account(email = unique_address())
order   = place_order(account, items = [sample_item()])
assert order_status(order.id) == "PLACED"   # guard: setup really worked
cancel_order(order.id)
assert order_status(order.id) == "CANCELLED"
cleanup: remove_account(account)

go deeper

for a junior

Recall the core rule: a case should create the data it uses. If you cannot point at the line that made a record the case reads, the case is relying on luck, and it will fail somewhere else for a reason nobody can explain.

for a middle

Explain the mechanics. Walk the setup listing each borrowed fact, name the collision risks of shared and newest-record assumptions, and show the guard assertion that makes a bad precondition fail at the setup instead of in the middle of the flow.

for a senior

Show production judgement about where to spend setup cost. Argue which preconditions must go through the product's own paths and which may be written directly, what an unreachable starting condition does to a case's meaning, and how you keep cases from leaving residue behind.

for a principal

Own the seam. Decide who provides the data-creation surface every case builds on, what guarantees a target environment offers so cases need not re-create the world, and how you stop each team inventing an incompatible way to make an account.

What "honest setup" means

A case is honest about its setup when every fact it depends on is either created by the case itself or is a stated, guaranteed property of the target it runs against — and when the case says so out loud. Everything else is a borrowed assumption: something that happened to be true when the case was written, carried forward silently.

Machine-drafted end-to-end and service cases borrow assumptions constantly, and for a structural reason. The draft is produced from a session that ran in a world that already existed: the account was there, the catalogue had stock, the user was already enrolled, the previous order was already in a settled status. None of that appears in the trace as a step, so none of it appears in the draft as a line. The draft looks complete because everything it needs was already true.

Where drafted setups go wrong

The uncreated record. The case reads or acts on an identifier no line in the case ever produced. It passes wherever that record happens to exist and fails everywhere else, for a reason that has nothing to do with the behaviour.
The pinned identifier. A reference lifted from the drafting session. After a data refresh, or against a second deployed target, it is simply gone.
The ordering assumption. "the most recent order", "the first row returned". True when the case runs alone; false the moment two runs overlap or another case writes.
The shared standing account. The draft reuses a long-lived account and mutates it. It works in isolation and collides as soon as anything else touches the same record.
The unstated precondition. Nothing checks the starting condition, so a half-applied setup does not fail at the setup — it surfaces in the middle of the case and reads like a product defect.
The unreachable starting condition. The setup writes straight into the store and manufactures a combination the product itself could never produce. The case then proves behaviour over a world that does not exist.
No ownership of what it created. The case leaves records behind that the next run trips over, or that quietly make a later assertion pass for the wrong reason.

Reading the setup, in order

List every fact the case relies on before its first meaningful action.
For each one, find the line that created it. If there is no such line, the case is borrowing — ask whether the borrow is documented and guaranteed.
Check uniqueness: could two runs of this case at the same moment claim the same record?
Check the guard: if a precondition is wrong, does the case stop there and say which precondition, or does it carry on and fail somewhere confusing?
Check reachability: could the product's own paths have produced this starting condition?
Check ownership: what does the case leave behind, and does anything else care?

Creating through the product versus writing straight into the store

Aspect	Created through the product's own paths	Written straight into the store
Speed	Slower; every precondition costs a real flow	Fast; one write per fact
Fidelity of the starting condition	High — it is a condition the product can reach	Only as good as the writer's model of the schema
Risk of an impossible world	Low	Real; invariants the product maintains can be skipped
Coupling	To the product's public behaviour	To internal structure, which moves
When setup breaks	You have found a real defect in a real flow	You have found a drift between your writer and the product
Good fit for	The precondition closest to the behaviour under test	Bulk background data far from the behaviour

Neither column is the right answer everywhere. The reviewer's judgement is about distance: the precondition immediately under the behaviour being tested is worth creating the honest way, because if that path is broken the case should fail; background data three steps removed is not worth the runtime.

Making a false precondition fail loudly

The cheapest improvement to most drafted setups is a guard: after the setup and before the first action, assert that the starting condition is what the case believes. It costs one line and it moves a whole class of confusing failures out of the behaviour under test. Without it, a setup that half worked produces a failure deep in the flow, and the first person to look at it starts by investigating a feature that was never broken.

The review comment

Concrete beats abstract. The comments that land are the small ones: "this reads an account the case never creates — create it in setup, or state where the guarantee comes from", "this claims the newest record; give the case its own identifier so parallel runs cannot collide", "assert the starting condition here so a bad setup fails at the setup". Each is a one-line edit, and each turns a case that passes because of its surroundings into one that passes because the system works.

## What "honest setup" means A case is honest about its setup when every fact it depends on is either created by the case itself or is a stated, guaranteed property of the target it runs against — and when the case says so out loud. Everything else is a **borrowed assumption**: something that happened to be true when the case was written, carried forward silently. Machine-drafted end-to-end and service cases borrow assumptions constantly, and for a structural reason. The draft is produced from a session that ran in a world that already existed: the account was there, the catalogue had stock, the user was already enrolled, the previous order was already in a settled status. None of that appears in the trace as a **step**, so none of it appears in the draft as a **line**. The draft looks complete because everything it needs was already true. ## Where drafted setups go wrong - **The uncreated record.** The case reads or acts on an identifier no line in the case ever produced. It passes wherever that record happens to exist and fails everywhere else, for a reason that has nothing to do with the behaviour. - **The pinned identifier.** A reference lifted from the drafting session. After a data refresh, or against a second deployed target, it is simply gone. - **The ordering assumption.** *"the most recent order"*, *"the first row returned"*. True when the case runs alone; false the moment two runs overlap or another case writes. - **The shared standing account.** The draft reuses a long-lived account and mutates it. It works in isolation and collides as soon as anything else touches the same record. - **The unstated precondition.** Nothing checks the starting condition, so a half-applied setup does not fail at the setup — it surfaces in the middle of the case and reads like a product defect. - **The unreachable starting condition.** The setup writes straight into the store and manufactures a combination the product itself could never produce. The case then proves behaviour over a world that does not exist. - **No ownership of what it created.** The case leaves records behind that the next run trips over, or that quietly make a later assertion pass for the wrong reason. ## Reading the setup, in order 1. List every fact the case relies on before its first meaningful action. 2. For each one, find the line that created it. If there is no such line, the case is borrowing — ask whether the borrow is documented and guaranteed. 3. Check uniqueness: could two runs of this case at the same moment claim the same record? 4. Check the guard: if a precondition is wrong, does the case stop there and say which precondition, or does it carry on and fail somewhere confusing? 5. Check reachability: could the product's own paths have produced this starting condition? 6. Check ownership: what does the case leave behind, and does anything else care? ## Creating through the product versus writing straight into the store | Aspect | Created through the product's own paths | Written straight into the store | | --- | --- | --- | | Speed | Slower; every precondition costs a real flow | Fast; one write per fact | | Fidelity of the starting condition | High — it is a condition the product can reach | Only as good as the writer's model of the schema | | Risk of an impossible world | Low | Real; invariants the product maintains can be skipped | | Coupling | To the product's public behaviour | To internal structure, which moves | | When setup breaks | You have found a real defect in a real flow | You have found a drift between your writer and the product | | Good fit for | The precondition closest to the behaviour under test | Bulk background data far from the behaviour | Neither column is the right answer everywhere. The reviewer's judgement is about **distance**: the precondition immediately under the behaviour being tested is worth creating the honest way, because if that path is broken the case should fail; background data three steps removed is not worth the runtime. ## Making a false precondition fail loudly The cheapest improvement to most drafted setups is a guard: after the setup and before the first action, assert that the starting condition is what the case believes. It costs one line and it moves a whole class of confusing failures out of the behaviour under test. Without it, a setup that half worked produces a failure deep in the flow, and the first person to look at it starts by investigating a feature that was never broken. ## The review comment Concrete beats abstract. The comments that land are the small ones: *"this reads an account the case never creates — create it in setup, or state where the guarantee comes from"*, *"this claims the newest record; give the case its own identifier so parallel runs cannot collide"*, *"assert the starting condition here so a bad setup fails at the setup"*. Each is a one-line edit, and each turns a case that passes because of its surroundings into one that passes because the system works.

When is it acceptable for a drafted case to write its starting condition straight into the store?
When the data is background rather than the behaviour under test — bulk history, a catalogue, an unrelated prior record — and when the shortcut cannot manufacture a combination the product itself could not reach. The precondition immediately beneath the behaviour is different: create it the honest way, because if that path is broken the case should notice. Direct writes also couple the case to internal structure, so they need an owner.
A drafted case asserts nothing between its setup and its first action. What do you ask for?
A guard: one assertion that the starting condition is what the case believes. Without it, a setup that half succeeded produces a failure in the middle of the flow, and whoever triages it begins by investigating a feature that was never broken. The guard costs one line and converts a confusing behavioural failure into an obvious setup failure.

saying these in an interview costs you the question

Assumes the data will be there because it was there before
Reuses a standing shared account and mutates it
Relies on the newest or first record being its own
Says setup is not worth reviewing because it is not the test
Writes an impossible starting condition straight into the store

When reviewing a machine-drafted service case, how do you judge whether its setup and assumed data are honest?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What "honest setup" means

Where drafted setups go wrong

Reading the setup, in order

Creating through the product versus writing straight into the store

Making a false precondition fail loudly

The review comment

▾common follow-ups2 questions

▾red flags5 flags

What "honest setup" means

Where drafted setups go wrong

Reading the setup, in order

Creating through the product versus writing straight into the store

Making a false precondition fail loudly

The review comment

answer

go deeper