A sign-up test resets the product's database between runs. What recipient state survives that reset?

middleshould knowfreq 40%

answer

Not all of it is yours to reset
Ask who else remembers this recipient
The claim outlives the account row
Confirmed, subscribed, suppressed, leased

basics

~20 s

Recipient identities live outside the product: the mailbox or number the run claimed, the address confirmed with the delivery side, the consent and subscription records, and any suppression entry. Resetting the product's tables removes none of them.

solid answer

~50 s

A sign-up case creates state in at least three places, and only one of them is the product's database. The recipient claim — a mailbox claimed at a capture service, or a number leased from a pool — is still held after the reset. The delivery side keeps its own records: the address is marked confirmed, it may sit on a subscription list, and an earlier bounce or unsubscribe can have put it on a suppression list that silently drops later messages to it. The earlier messages are still in the mailbox. The product's own row is gone, so the next run cheerfully registers the same address again, against an outside world that already has an opinion about it. Treat each of those as owned test state with a lifetime, not as a side effect.

A sign-up case creates state in at least three places, and only one of them is the product's database. The **recipient claim** — a mailbox claimed at a capture service, or a number leased from a pool — is still held after the reset. The **delivery side** keeps its own records: the address is marked confirmed, it may sit on a subscription list, and an earlier bounce or unsubscribe can have put it on a suppression list that silently drops later messages to it. The **earlier messages** are still in the mailbox. The product's own row is gone, so the next run cheerfully registers the same address again, against an outside world that already has an opinion about it. Treat each of those as owned test state with a lifetime, not as a side effect.

code

pseudocode · 8 lines

pseudocode

# one passing sign-up case, sorted by where its state lands
product.register(address)            # row in the product's tables  -> cleared by the reset
capture.claim(address)               # mailbox claim               -> still held
delivery.mark_confirmed(address)     # confirmed-recipient record  -> still held
delivery.subscribe(address, "news")  # consent record              -> still held
pool.lease(number, owner = run_id)   # leased number               -> still held

reset_product_tables()               # reaches the first line, and nothing below it

go deeper

for a junior

Be ready to say where a test's data actually lives. Recall that a sign-up case touches the product's own records and, separately, whatever system holds the mailbox or the number it used.

for a middle

Explain the mechanics: which leftovers — a claimed mailbox, a confirmed address, subscription or consent state, a leased number, earlier arrivals — survive a reset of the product's tables, and why the reset cannot reach any of them.

for a senior

Show that you treat each identity as owned state with a lifetime. An interviewer expects you to name the failures the residue causes in a long-running suite and say, per artefact, who reclaims it and when.

for a principal

Own the policy angle: which identities the organisation is willing to hold at all, for how long, and who owns the quota when several suites mint recipients against the same shared capacity.

What the database reset actually reaches

A suite that resets the product's database between runs is doing something precise and narrow: it restores the tables the product owns. A notification case, by definition, does work that crosses out of those tables — sending a message to a person is an act performed against a system the product does not own — so a large part of what such a case creates sits on the far side of the boundary that reset can reach.

It helps to draw that boundary explicitly and put every artefact on one side of it.

Inside the product: the account row, the flag the product stores to say the address was confirmed, the preference column, the audit entry it wrote when it sent. All of that is restored by the reset, and none of it is the subject here.

Outside the product, reachable only through whatever interface that other system exposes:

The recipient claim. The mailbox the case reads was claimed at a capture service; the phone number was leased from a pool. A claim is a resource with an owner, a quota and a lifetime, and it is still held after the reset.
The confirmed address. Confirmation is normally recorded on both sides. The product's flag disappears with the reset; the record on the delivery side — this address has been confirmed, we may send to it — does not.
Subscription and consent state. An address added to a list, or one that followed an unsubscribe link during an earlier case, carries that decision forward. Consent is deliberately built to outlive an account, precisely so that deleting and recreating an account cannot be used to re-enable messaging.
Suppression state. A hard bounce, a complaint or an unsubscribe usually writes an entry that causes later messages to that address to be dropped before delivery is even attempted. It is designed to be sticky.
The delivered messages themselves. Copies from earlier runs are still sitting in that mailbox, and they match subject and body assertions exactly as well as a fresh arrival does.

Why the passing path creates the most residue

The intuition to unlearn is that residue comes from failures. It is the other way round. Registering, confirming and subscribing are the steps under test, so a case that passes has performed all of them and each one wrote something outside the product. A case that fails at step one may leave almost nothing behind. A suite's healthiest, greenest runs are its most productive source of leftovers.

Artefact	Where it lives	Effect of the product reset	How it is reclaimed
Claimed mailbox	capture service	none	released explicitly, or expired by age
Leased number	number pool	none	released, often after a cooling period
Confirmed address	delivery side	none	removed with the address, or expired
Subscription / consent	delivery side	none	re-subscribed, or the address forgotten
Suppression entry	delivery side	none	frequently cannot be cleared on demand
Account and audit rows	the product	removed	the reset itself

The right-hand column is the useful one. Some residue you may delete whenever you like, some you can only release and then wait out, and some you cannot clear at all. That asymmetry is why the identity itself, rather than the individual records it created, becomes the thing you manage.

What it costs as the suite ages

Three costs arrive in roughly this order.

Quota. Claims and leases are finite. A suite that mints an identity per run and releases none will eventually be unable to start. This one is easy to diagnose because it is total and it is loud.
Untrustworthy results. Long before quota runs out, a reused identity that carries state distorts outcomes: an assertion satisfied by an earlier run's copy, or a delivery that never happens because the address was suppressed months ago. This is the expensive cost, because it is silent.
Undebuggable evidence. A recipient holding a year of accumulated arrivals is useless for diagnosis; nothing tells you which artefact belongs to the failure in front of you.

Treating identities as owned state

The working practice is to treat every identity a case creates as owned test state with a declared lifetime, exactly as you would treat a temporary file or an allocated port — and to record it somewhere that does not require the run to survive:

Register the claim at creation in a store outside the run's memory, carrying at least an owner and a created_at.
Give the identity a marker that lets a later process tell test identities apart from real ones without guessing.
Decide, per artefact type, whether it is released, forgotten, or simply allowed to age out — the three are not interchangeable.
Assert the starting condition your case depends on. If it needs an empty mailbox, check for one rather than assume it.

The sentence to carry into an interview: a database reset is a statement about the product's tables, not about the world. A notification case's most consequential leftovers all live in the part of the world that reset cannot see.

## What the database reset actually reaches A suite that resets the product's database between runs is doing something precise and narrow: it restores the tables the product owns. A notification case, by definition, does work that crosses out of those tables — sending a message to a person is an act performed against a system the product does not own — so a large part of what such a case creates sits on the far side of the boundary that reset can reach. It helps to draw that boundary explicitly and put every artefact on one side of it. **Inside the product:** the account row, the flag the product stores to say the address was confirmed, the preference column, the audit entry it wrote when it sent. All of that is restored by the reset, and none of it is the subject here. **Outside the product**, reachable only through whatever interface that other system exposes: - **The recipient claim.** The mailbox the case reads was claimed at a capture service; the phone number was leased from a pool. A claim is a resource with an owner, a quota and a lifetime, and it is still held after the reset. - **The confirmed address.** Confirmation is normally recorded on both sides. The product's flag disappears with the reset; the record on the delivery side — *this address has been confirmed, we may send to it* — does not. - **Subscription and consent state.** An address added to a list, or one that followed an unsubscribe link during an earlier case, carries that decision forward. Consent is deliberately built to outlive an account, precisely so that deleting and recreating an account cannot be used to re-enable messaging. - **Suppression state.** A hard bounce, a complaint or an unsubscribe usually writes an entry that causes later messages to that address to be dropped before delivery is even attempted. It is designed to be sticky. - **The delivered messages themselves.** Copies from earlier runs are still sitting in that mailbox, and they match subject and body assertions exactly as well as a fresh arrival does. ## Why the passing path creates the most residue The intuition to unlearn is that residue comes from failures. It is the other way round. Registering, confirming and subscribing are the steps under test, so a case that passes has performed all of them and each one wrote something outside the product. A case that fails at step one may leave almost nothing behind. A suite's healthiest, greenest runs are its most productive source of leftovers. | Artefact | Where it lives | Effect of the product reset | How it is reclaimed | |---|---|---|---| | Claimed mailbox | capture service | none | released explicitly, or expired by age | | Leased number | number pool | none | released, often after a cooling period | | Confirmed address | delivery side | none | removed with the address, or expired | | Subscription / consent | delivery side | none | re-subscribed, or the address forgotten | | Suppression entry | delivery side | none | frequently cannot be cleared on demand | | Account and audit rows | the product | removed | the reset itself | The right-hand column is the useful one. Some residue you may delete whenever you like, some you can only release and then wait out, and some you cannot clear at all. That asymmetry is why the identity itself, rather than the individual records it created, becomes the thing you manage. ## What it costs as the suite ages Three costs arrive in roughly this order. 1. **Quota.** Claims and leases are finite. A suite that mints an identity per run and releases none will eventually be unable to start. This one is easy to diagnose because it is total and it is loud. 2. **Untrustworthy results.** Long before quota runs out, a reused identity that carries state distorts outcomes: an assertion satisfied by an earlier run's copy, or a delivery that never happens because the address was suppressed months ago. This is the expensive cost, because it is silent. 3. **Undebuggable evidence.** A recipient holding a year of accumulated arrivals is useless for diagnosis; nothing tells you which artefact belongs to the failure in front of you. ## Treating identities as owned state The working practice is to treat every identity a case creates as **owned test state with a declared lifetime**, exactly as you would treat a temporary file or an allocated port — and to record it somewhere that does not require the run to survive: - Register the claim at creation in a store outside the run's memory, carrying at least an `owner` and a `created_at`. - Give the identity a marker that lets a later process tell test identities apart from real ones without guessing. - Decide, per artefact type, whether it is released, forgotten, or simply allowed to age out — the three are not interchangeable. - Assert the starting condition your case depends on. If it needs an empty mailbox, check for one rather than assume it. The sentence to carry into an interview: **a database reset is a statement about the product's tables, not about the world.** A notification case's most consequential leftovers all live in the part of the world that reset cannot see.

Which of those leftovers can the suite delete itself, and which can it only wait out?
A mailbox claim and a subscription can usually be released or reversed on demand. A leased number often has a cooling period before it can be re-leased, and a suppression entry is deliberately sticky and frequently cannot be cleared at all. That split is why the identity, rather than each record it created, becomes the unit you manage and expire.
Why does a passing case leave more residue than a failing one?
Because registering, confirming and subscribing are the steps under test. A case that passes has performed every one of them, and each wrote something outside the product. A case that fails at the first step may leave almost nothing. The suite's healthiest runs are its biggest producers of leftovers, which is the opposite of most people's intuition.

Closing your account with a shop does not un-sign you from its mailing list. A different system holds that record, and it goes on holding it.

saying these in an interview costs you the question

Claims a database reset undoes everything a case created
Thinks only failing cases leave residue behind
Treats consent and suppression records as product rows
Assumes deleting the account removes the confirmed address
Believes an unused address stays neutral indefinitely

A sign-up test resets the product's database between runs. What recipient state survives that reset?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the database reset actually reaches

Why the passing path creates the most residue

What it costs as the suite ages

Treating identities as owned state

▾common follow-ups2 questions

▾analogy~10 s

▾red flags5 flags

What the database reset actually reaches

Why the passing path creates the most residue

What it costs as the suite ages

Treating identities as owned state

answer

go deeper