What must each parallel test worker hold uniquely for a case to run safely beside a copy of itself?

middleshould knowfreq 48%

answer

Ask what two copies would share
Every constant is a collision candidate
Identity, bound port, written path, global setting
Derive the value from the worker index

basics

~20 s

Anything the case names by a constant is a collision candidate: the identity it signs in as, any fixed local port it binds, the paths it writes evidence to, and any single record or global setting it changes in place.

solid answer

~50 s

The identity it acts as. Two copies on one account share a profile, one authenticated user session and one per-account limit.
Anything bound on the host. A fixed local port either refuses the second copy or, worse, lets the two receive each other's traffic.
Every path it writes. Fixed evidence file names mean a failure is investigated with the other copy's artefacts.
Anything it changes in place. A single record or a setting global to the target.

The heuristic: every constant in the case is a collision candidate until something makes it per-worker.

Run one case as four copies at the same moment — a copy of itself is the worst possible neighbour, because it wants every resource at exactly the same point in the flow. Four categories have to be per-worker: - **The identity it acts as.** Two copies on one account share a profile, one authenticated user session and one per-account limit. - **Anything bound on the host.** A fixed local port either refuses the second copy or, worse, lets the two receive each other's traffic. - **Every path it writes.** Fixed evidence file names mean a failure is investigated with the other copy's artefacts. - **Anything it changes in place.** A single record or a setting global to the target. The heuristic: every constant in the case is a collision candidate until something makes it per-worker.

code

pseudocode · 7 lines

pseudocode

# Self-concurrency check: run one case four times at once
run_concurrently(case = "checkout_charges_once", copies = 4)

# Turn the case's constants into per-worker values
actor     = identity_pool[worker_index]      # not one shared login
receiver  = bind(port = ANY_FREE)            # not a named port
evidence  = output_root / worker_index / case_name

go deeper

for a junior

Be ready to say why two copies of one case can interfere at all: if both use the same login, the same file name or the same fixed record, the second one changes what the first is looking at.

for a middle

Name the categories rather than one example — the identity signed in as, anything bound on the host, every path written, and anything changed in place — and say how each is made per-worker.

for a senior

Show the discipline of proving it: run a case against copies of itself before trusting it at width, and treat every constant in the case as a collision candidate until something makes it per-worker.

for a principal

Own the convention rather than the individual fix. Decide what the harness supplies by default — identities from a pool, ports assigned rather than named, paths stamped with the worker index — so no case author has to remember, and the self-concurrency run becomes an audit.

The test that answers the question

The reliable way to find out what a case needs uniquely is not to reason about it — it is to run the case against copies of itself. Take one case, launch four of it at the same moment against the same target, and watch. A case that survives that is safe beside any other case doing the same things, because a copy of itself is the worst possible neighbour: it wants every resource the original wants, at exactly the same point in the flow.

Cases fail this test far more often than they fail a mixed parallel run, which is why it is worth doing deliberately rather than waiting for the suite to widen.

The categories that must be per-worker

What the case names	How the collision shows up	What makes it per-worker
The identity it signs in as	one copy changes a preference or a profile the other is asserting on; one copy's sign-out ends the other's authenticated user session; a per-identity limit trips	a pool of identities, one handed to each worker
Anything it binds on the host	a fixed local port refuses to bind for the second copy — or worse, binds fine and the two copies receive each other's traffic	ask for any free port and pass the assigned value onward
Every path it writes	evidence files overwrite each other, so a failure is investigated with another copy's screenshot	put the worker's own index into the path
A single record or setting it changes in place	one copy edits the thing the other is reading, and both assertions become non-deterministic	mint what can be minted; declare exclusivity for what cannot

Why "it creates its own data" is not the whole answer

The most common wrong answer is that a case is concurrency-safe as soon as it creates its own records. Records are only one of the four categories, and they are usually the one people already thought about.

Two copies that each create a fresh record can still collide because they sign in as the same account: they share one profile, one set of preferences, one notification list, one per-account quota. They can collide because both write to a path named after the case, so whichever finishes last owns the evidence. They can collide because both bind the same local port for a receiver they stand up. And they can collide because both flip one setting on the target that is global to it — a toggle, a system-wide configuration value — where uniqueness is not even available as a fix.

The heuristic worth remembering

Every constant in a case is a collision candidate until something makes it per-worker. A literal account name, a literal port number, a literal file path, a literal record identifier, a literal directory: each one is an assertion that the case owns that thing exclusively, made silently, and true only while the case runs alone.

The corollary is the repair: replace the constant with a value derived from the worker's own identity, or with one the case mints at run time, or with a value the surrounding system assigns and hands back. Three shapes cover nearly everything:

Take from a pool indexed by the worker. Identities, seeded accounts, reserved slots.
Ask instead of declare. Request any free port, any temporary directory, and use what comes back.
Stamp with the worker. Output paths and file names that carry the worker's index cannot overwrite each other.

What cannot be made unique

Some things are singular by nature and no amount of per-worker naming changes that: a setting global to the whole deployed target, a scheduler that runs once, a resource the product models as one. For those, uniqueness is the wrong tool — the case needs exclusivity, declared and scheduled, so that it and its neighbours take turns rather than pretending to be independent. The important discipline is telling the two apart: if you can name a per-worker version of the thing, make one; if you genuinely cannot, say so out loud in the suite's model instead of hoping the timing works out.

Making it stick

The worst outcome is a rule that lives in people's heads. Whatever the answer is for your suite — identities come from a pool, ports are assigned rather than named, paths carry the worker index — it should be something the harness supplies by default so that a case author never has to remember it. Then the self-concurrency run becomes an audit rather than a debugging session: anything that still fails at four copies is a case that reached around the convention, and the failure names it directly.

## The test that answers the question The reliable way to find out what a case needs uniquely is not to reason about it — it is to run the case against copies of itself. Take one case, launch four of it at the same moment against the same target, and watch. A case that survives that is safe beside any other case doing the same things, because a copy of itself is the worst possible neighbour: it wants every resource the original wants, at exactly the same point in the flow. Cases fail this test far more often than they fail a mixed parallel run, which is why it is worth doing deliberately rather than waiting for the suite to widen. ## The categories that must be per-worker | What the case names | How the collision shows up | What makes it per-worker | | --- | --- | --- | | **The identity it signs in as** | one copy changes a preference or a profile the other is asserting on; one copy's sign-out ends the other's authenticated user session; a per-identity limit trips | a pool of identities, one handed to each worker | | **Anything it binds on the host** | a fixed local port refuses to bind for the second copy — or worse, binds fine and the two copies receive each other's traffic | ask for any free port and pass the assigned value onward | | **Every path it writes** | evidence files overwrite each other, so a failure is investigated with another copy's screenshot | put the worker's own index into the path | | **A single record or setting it changes in place** | one copy edits the thing the other is reading, and both assertions become non-deterministic | mint what can be minted; declare exclusivity for what cannot | ## Why "it creates its own data" is not the whole answer The most common wrong answer is that a case is concurrency-safe as soon as it creates its own records. Records are only one of the four categories, and they are usually the one people already thought about. Two copies that each create a fresh record can still collide because they **sign in as the same account**: they share one profile, one set of preferences, one notification list, one per-account quota. They can collide because both **write to a path named after the case**, so whichever finishes last owns the evidence. They can collide because both **bind the same local port** for a receiver they stand up. And they can collide because both **flip one setting on the target** that is global to it — a toggle, a system-wide configuration value — where uniqueness is not even available as a fix. ## The heuristic worth remembering **Every constant in a case is a collision candidate until something makes it per-worker.** A literal account name, a literal port number, a literal file path, a literal record identifier, a literal directory: each one is an assertion that the case owns that thing exclusively, made silently, and true only while the case runs alone. The corollary is the repair: replace the constant with a value derived from the worker's own identity, or with one the case mints at run time, or with a value the surrounding system assigns and hands back. Three shapes cover nearly everything: 1. **Take from a pool indexed by the worker.** Identities, seeded accounts, reserved slots. 2. **Ask instead of declare.** Request any free port, any temporary directory, and use what comes back. 3. **Stamp with the worker.** Output paths and file names that carry the worker's index cannot overwrite each other. ## What cannot be made unique Some things are singular by nature and no amount of per-worker naming changes that: a setting global to the whole deployed target, a scheduler that runs once, a resource the product models as one. For those, uniqueness is the wrong tool — the case needs **exclusivity**, declared and scheduled, so that it and its neighbours take turns rather than pretending to be independent. The important discipline is telling the two apart: if you can name a per-worker version of the thing, make one; if you genuinely cannot, say so out loud in the suite's model instead of hoping the timing works out. ## Making it stick The worst outcome is a rule that lives in people's heads. Whatever the answer is for your suite — identities come from a pool, ports are assigned rather than named, paths carry the worker index — it should be something the harness supplies by default so that a case author never has to remember it. Then the self-concurrency run becomes an audit rather than a debugging session: anything that still fails at four copies is a case that reached around the convention, and the failure names it directly.

A case stands up a receiver on a fixed local port. What is the smallest change that makes it safe beside a copy of itself?
Ask for any free port rather than naming one, then pass the assigned value to whatever must reach it through configuration the case controls. The case stops asserting ownership of something it does not own, and any number of copies coexist. A per-worker port range also works, but only while the worker count stays bounded.
Why can two copies of one case collide even when each creates its own records?
Because records are one category of four. Two copies signing in as the same identity share a profile, one authenticated user session and one per-account limit; two copies writing evidence to the same file name overwrite each other; two copies flipping one setting that is global to the target read each other's value.

saying these in an interview costs you the question

Thinks unique data is the whole of per-worker uniqueness
Signs every worker in as the same shared account
Binds a fixed local port and calls the case deterministic
Writes evidence to one file name derived from the case name
Assumes a case that passes alone is concurrency-safe
Never runs a case against copies of itself

What must each parallel test worker hold uniquely for a case to run safely beside a copy of itself?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The test that answers the question

The categories that must be per-worker

Why "it creates its own data" is not the whole answer

The heuristic worth remembering

What cannot be made unique

Making it stick

▾common follow-ups2 questions

▾red flags6 flags

The test that answers the question

The categories that must be per-worker

Why "it creates its own data" is not the whole answer

The heuristic worth remembering

What cannot be made unique

Making it stick

answer

go deeper