skip to content

Why should an automated case ask its provisioning seam for an account already in the condition it needs, rather than name a known record identifier?

level: middleimportance: should knowfreq 55%

answer

  1. Say what you need, not which row
  2. The case should carry its own premise
  3. Meaning drifts, identifiers do not
  4. Find-or-create belongs behind the seam
  5. Reference data is the honest exception

basics

~20 s

Naming the condition — an account whose trial has ended — lets the seam satisfy it on any deployed target and puts the case's premise in the case. A pinned identifier assumes a record whose meaning can drift unnoticed.

solid answer

~50 s

A case's real precondition is a **state**, not a row: *an account whose trial has ended*, *an order that has shipped*. When the case asks for that state, the seam is free to satisfy it however it can — create a record and drive it there, or find one that already qualifies — and the case documents what it needs in its own text. A pinned identifier inverts both properties. It ties the case to one record on one prepared target, and it hides the precondition: nothing in the case explains why account 4471 was chosen. When someone edits that record — settles its balance, extends its trial — the case does not announce that its premise is gone. It either fails with a message that points at the product, or quietly stops exercising the behaviour its name claims.

code

pseudocode · 17 lines
pseudocode
# pinned: nothing says why 4471, and nothing notices when 4471 changes
case "expired trial sees the upgrade prompt":
    app.sign_in(account_id = 4471)
    assert app.prompt().says("your trial has ended")

# stated: the premise is in the case, the seam decides how to reach it
case "expired trial sees the upgrade prompt":
    account = provisioning.account(trial = "ended")
    app.sign_in(account.credentials)
    assert app.prompt().says("your trial has ended")

# one way the seam may satisfy the request
function account(trial):
    made = create_account()
    if trial == "ended":
        move_trial_clock(made, past_end = true)
    return made

go deeper

for a junior

Be ready to say in words what must be true before your case runs — an account whose trial has ended — rather than pointing at a record number somebody prepared for you.

for a middle

Explain how a request for a state gets satisfied: create a record and drive it there, or find one that already qualifies. Be able to say what each choice costs in determinism.

for a senior

Show the diagnosis angle. An interviewer expects you to explain how a case pinned to a record can keep passing while testing nothing, and how you would go looking for that in a suite you inherited.

for a principal

Own the vocabulary decision. Which states the seam offers as first-class requests decides what the suite can express cheaply, and a seam that only hands out identifiers pushes state-building into every case that needs one.

Every automated case begins with a premise: something must already be true before the check means anything. How the case *expresses* that premise decides whether it stays honest as the product, the data and the deployed targets move underneath it. ## The premise is a state, not a row Read a case's name and you can usually recover its premise in words: *an account whose trial has ended sees the upgrade prompt*. The words name a **state** — a condition over the product's data — and that is exactly what the case should ask its provisioning seam for. The request carries the premise; the seam works out how to produce something that satisfies it. A pinned identifier says something different and much weaker: *there exists, on this target, a record numbered 4471, and I am told it has the property I need*. Two facts about the world are now assumptions, and neither is checked. ## What a pinned identifier actually assumes | | Pinned record identifier | Stated state | | --- | --- | --- | | Premise visible in the case | No — a number carries no meaning | Yes — the request is the premise | | Works on a freshly built target | No — the record must be put there first | Yes — the seam produces it | | Survives an edit to the record | No — silently | Yes — the state is re-established per run | | Failure when the premise breaks | Points at the product | Points at provisioning | | Reader can tell what the case needs | Only by looking the record up | From the case text | The third and fourth rows are the ones that bite. A record's identifier is stable; its *meaning* is not. Someone extends the trial on account 4471 to reproduce a support ticket, and the case that depended on that trial being over now fails with an assertion message about a missing prompt — a message that sends the reader to the product first and the data last. The worse variant is the case that keeps passing: if the premise inverts in a direction the assertion happens to tolerate, nothing goes red at all and the behaviour simply stops being covered. ## How a seam satisfies a state request - **Create and drive.** Make a fresh record, then move it into the requested state through whatever mechanism the seam uses. The most deterministic option, and the default worth preferring. - **Find or create.** Look for an existing record that already qualifies and fall back to creating one. Cheaper for expensive setups, but the case now shares a record with anything else that could find it, and a failure is harder to reproduce because the record differs run to run. - **Claim from a pool.** Take a pre-built record already in the state, and put it back afterwards. Fast, at the cost of maintaining the pool and of records that carry the residue of earlier use. The case sees none of this, which is the point. What it does see is the vocabulary, and the vocabulary is where the states that matter get named once instead of being reconstructed by hand in every case that needs them. ## Writing the request Keep the request in the product's language and at the granularity of the behaviour. *An account whose trial has ended* is a good request; *an account whose trial ended between eight and eleven days ago with two prior invoices and no payment method* is a case's own detail smuggled into the vocabulary. The distinction is whether other cases would ask for the same thing. If only one case wants it, provision the plain record and let that case apply the rest. Where a number genuinely matters to the check — suppose the prompt is only supposed to appear once the trial has been over for more than seven days — that number belongs in the case, applied against a record the seam provisioned, so a reader can see the boundary being tested rather than inferring it from a row. ## When a fixed identifier is defensible There is an honest exception: immutable reference data the product ships and never changes — a currency, a country, a tax band, a system role. Nothing in a run creates it, no run can move it, and its meaning is stable by definition. Even then, prefer a named constant to a bare number, so the case says what the value means rather than what it is. Everything else — accounts, orders, subscriptions, documents — is data a run can change, which is precisely why the case should say what it needs rather than which row it was handed. ## The failure you will not notice The reason this is worth an interview question is not the loud failure; it is the quiet one. A suite that pins identifiers degrades gradually: a few cases stop asserting anything meaningful, they stay green, and the coverage they represent evaporates without a single red build. The only cheap defence is to make the premise part of the case, where a reader can see it and a run re-establishes it.

  • When is naming a fixed record identifier in a case actually correct?
    When the record is reference data the product ships and treats as immutable — a currency, a country, a tax band. Nothing in a run creates it, nothing can move it, and its meaning is stable by definition. Even then, bind it to a named constant rather than writing the bare number, so the case tells a reader what the value means instead of what it is.
  • The seam satisfies a state request by finding an existing record that already qualifies. What does that cost you?
    Determinism and ownership. The case now shares a record with anything else that could find it, so a concurrent run can move it out of the requested state mid-case, and a failure is hard to reproduce because the record differs each time. Find-or-create is a reasonable optimisation for expensive setups, but it should be a deliberate choice and the case should record which record it was handed.
  • How would you find cases in an inherited suite whose premise has quietly stopped holding?
    Look for cases that reference records nothing in the run created, then re-establish each premise deliberately and see which assertions change. A blunter check works too: temporarily provision a fresh record for the case and see whether it still passes. A case that only passes against one prepared record is either testing that record or testing nothing.

Booking a hire car you ask for an estate with a tow bar, not for one specific number plate. The depot can satisfy the description a hundred ways, and the plate tells the next reader nothing about why you needed that car.

saying these in an interview costs you the question

  • Assuming a prepared target always contains the same records
  • Treating a record identifier as a stable description of state
  • Hiding the case's premise inside a numeric identifier
  • Repairing a drifted record by hand instead of stating the premise
  • Believing find-or-create is always equivalent to create