Should a driver session be created per case, per class, or per parallel test worker, and what does each cost?
answer
- Two costs pulling in opposite directions
- Ask what the previous case left behind
- Acquisition cost times cases, over workers
- Longer lifetime, wider blast radius
basics
~20 sDefault to a fresh driver session per case: it is the only lifetime that guarantees a clean start. Reuse across a class or a parallel worker only when acquisition is measurably slow; one case can then poison the next.
solid answer
~50 sThe choice trades **acquisition cost** against **contamination cost**. A session acquired per case is the only lifetime where every case provably starts from a known condition, and its blast radius is one case. A session shared across a class or held for the life of a parallel test worker pays the acquisition price once, but every later case inherits whatever the previous one left behind, so a single bad case turns into a run of unrelated red. Decide it with a measurement, not a preference: time one acquisition, multiply by the case count, divide by the number of workers, and compare that against the cost of investigating one false failure. Before trading isolation away, try to make acquisition cheaper — hoisting the expensive preparation and applying it at each acquisition keeps per-case isolation at most of the speed.
code
pseudocode · 12 lines# per-case lifetime: acquisition and release are scope-bound
for case in cases:
session = acquire_session(profile = prepared_profile)
scope.on_exit(release, session) # runs however the case ends
run(case, session)
# per-worker lifetime: acquired once, reused, reset between cases
session = acquire_session(profile = prepared_profile)
worker.on_exit(release, session)
for case in cases_for_this_worker:
reset_to_neutral(session) # now an obligation you own
run(case, session)go deeper
Be ready to name the three lifetimes and say which one guarantees a clean start. The short version interviewers want: fresh per case is slower and isolated, shared is faster and can carry problems forward.
Explain the trade with numbers rather than opinion: acquisition cost times case count over worker count, weighed against the cost of a failure that lands on the wrong case. Know that reuse creates a reset obligation you then own.
Show the diagnosis angle. Describe how a shared session produces order-dependent red that is not reproducible alone, and the mitigations you would put in place: discard a failed case's session, narrow the sharing scope, hoist the expensive preparation instead of the connection.
Own the policy for the whole suite. Say what the default lifetime is, what evidence lets a team deviate from it, and how you keep the exceptions from spreading once someone finds that sharing makes their run look fast.
## What a session lifetime actually decides A **driver session** is the live connection a case holds to the thing it operates: a client object on the test's side, plus whatever the other side keeps on the test's behalf — a window, a process, a connection, a working directory, a cache of settings that were applied once. Its **lifetime** is the scope at whose end that connection is released. Three scopes cover nearly every suite: - **Per case** — acquired before the case runs, released when it ends, pass or fail. - **Per class or file** — acquired once for a group of cases that run together, released when the group ends. - **Per parallel test worker** — acquired once when the worker starts and released when it stops, so every case that worker runs shares one connection. This is not a style preference. It is a trade between two costs that move in opposite directions: **creation cost**, paid once per session, and **contamination cost**, paid by every case that inherits a session another case already used. ## The three lifetimes side by side | Lifetime | Sessions per run | Clean start | Blast radius of one bad case | Typical fit | |---|---|---|---|---| | Per case | one per case | guaranteed for every case | the case itself | the sane default | | Per class | one per group | first case of the group only | the remaining cases in that group | creation is slow, the group is cohesive | | Per worker | one per worker | first case on that worker only | every later case that worker runs | creation genuinely dominates the run | Read the third column as the real product of the decision. A per-case lifetime is the only one that makes the sentence *"this case starts from a known state"* true by construction rather than by hope. Every longer lifetime replaces that guarantee with an obligation: something now has to put the session back to a neutral condition between cases, and that reset is code you have to write, maintain and prove. ## Put a number on the creation cost before trading isolation away Reuse is almost always argued for on speed, and the argument is usually made without a measurement. Do it in four steps: 1. **Time one acquisition** in isolation — not the whole first case, just the session coming up. 2. **Multiply by the case count and divide by the number of parallel workers.** Suppose acquisition takes 4 seconds, the suite has 900 cases and 6 workers run it: `900 * 4 / 6` is 600 seconds, so per-case sessions add about ten minutes of wall clock. 3. **Compare that against the cost of one contaminated failure.** A single false failure that is investigated by the wrong person, reproduced three times and eventually traced to a neighbouring case costs a working morning. Ten minutes of machine time is cheap next to it. 4. **Attack the creation cost first.** Much of what makes acquisition slow is not the connection itself but the preparation piled on top of it. Hoisting the expensive *preparation* — building a reusable starting profile once and applying it at each acquisition — keeps a fresh session per case while paying the expensive part once. ## What reuse actually hides The failure mode of a long-lived session is not that it fails. It is that it **moves the failure**. A case that puts the application into a bad condition and then passes leaves the next case to fail, and the next case's owner debugs a symptom that has nothing to do with the change they made. Three consequences follow, and all three are why a reused session is expensive even when it is fast: - **Failures stop being reproducible alone.** Running the failing case by itself passes, which is the most demoralising signal a suite can send. - **Blame lands on the wrong commit.** The case that appears red is chronologically after, not causally related to, the one that broke. - **Order becomes load-bearing.** Once a suite only passes in one order you have lost the freedom to shard it, re-run a subset, or run a single case locally. ## A middle path worth knowing When acquisition is genuinely expensive and per-case is genuinely unaffordable, the useful compromise is rarely "share for the whole run". Prefer the narrowest reuse that pays: share within a small, cohesive group whose cases were written together and are read together, and make the group's first act an explicit assertion that it starts from the condition it expects. Add one more rule: **any case that fails discards its session instead of handing it on.** A failed case is precisely the one most likely to have left something behind, so retiring its session removes the single largest source of downstream contamination while keeping most of the speed. That rule costs one extra acquisition per failure and buys back most of the isolation you traded away.
- A suite has 900 cases, acquisition takes four seconds, and six parallel test workers run it. How do you decide whether per-case acquisition is affordable?Compute it: 900 acquisitions at four seconds is 3600 seconds of work spread over six workers, about ten minutes of wall clock. Weigh that against one contaminated failure, which typically costs an engineer a morning. Ten minutes of machine time is usually the cheaper side, and if it is not, attack the four seconds before you give up isolation.
- If a case leaves the application on an error screen and the session is shared across its class, what happens next?The following cases in that class start from that error screen and fail at their first interaction, before they touch their own subject. The suite reports several failures, none of which is the real one, and each is investigated by whoever owns that case. The first red case in the group is the only one worth reading.
- When is sharing a session across a group of cases actually defensible?When acquisition is genuinely expensive, the group is small and cohesive, its cases were written and are read together, and the group's first act asserts the condition it expects. Add one rule: a case that fails discards its session rather than handing it on, since a failed case is the most likely one to have left residue behind.
A session per case is a fresh workbench for every job; a session per worker is one bench everybody shares, where the last person's mess becomes your first problem.
saying these in an interview costs you the question
- Claims reusing one session across the whole suite is always faster overall
- Cannot name anything a reused session carries from one case to the next
- Treats acquisition cost as fixed and never measures it
- Picks a lifetime without asking how a contaminated failure gets diagnosed
- Thinks a per-case session is unaffordable without ever timing one