skip to content

When a driver session is reused across cases, what must be reset between them, and what breaks when it is not?

level: middleimportance: should knowfreq 54%

answer

  1. The next case inherits, it does not start
  2. Enumerate what the session holds
  3. Location, stored data, overlays, permissions, settings
  4. Red case is not the wrong case
  5. Cannot list it, so recreate it

basics

~20 s

Reset everything the driver session carries: stored client data, the current location, open overlays, granted permissions, display size, and any per-case connection settings such as a shortened wait budget. Miss one and you get order-dependent failures in the wrong case.

solid answer

~50 s

A reused driver session hands the next case whatever the last one left. The reset list is short but must be **enumerated, not assumed**: client-side stored data, the location the session is parked on, open dialogs and overlays, permission decisions already made, viewport size, connection-level settings applied for one case such as a shortened wait budget or a request-interception rule, and any listeners or polling still running. Missing one produces an **order-dependent** failure with a distinctive signature — the case that goes red is not the case that is wrong, and it either passes alone or fails only after a particular predecessor. The practical rule: if you cannot enumerate what the session is holding, do not reset it, discard it and acquire a fresh one. Prove the reset by asserting the starting condition at the top of the shared preparation, and by running the suite shuffled on a schedule.

code

pseudocode · 15 lines
pseudocode
def reset_to_neutral(session):
    session.clear_stored_client_data()
    session.navigate(entry_point)
    session.dismiss_open_overlays()
    session.reset_permission_decisions()
    session.set_viewport(default_width, default_height)
    session.clear_interception_rules()
    session.restore_default_wait_budget()
    session.drain_captured_logs()

def prepare_case(session, case):
    reset_to_neutral(session)
    assert session.location == entry_point, \
        "previous case left the session elsewhere: " + session.location
    assert session.stored_client_data_is_empty()

go deeper

for a junior

Know that a reused driver session keeps whatever the last case left, and be able to name two or three things that carry over — where the session is parked, what the application stored on the client, and any dialog still open.

for a middle

Enumerate the reset list out loud and explain why an unenumerable condition means recreate rather than reset. Describe the two shapes of order dependence: passes in the suite but fails alone, and passes alone but fails in the suite.

for a senior

Show how you would prove the reset rather than trust it: assert the starting condition in shared preparation, record each case's predecessor so a report names the pair, and run shuffled on a schedule so order dependence has somewhere to surface.

for a principal

Take a position on where the boundary sits between resetting and recreating, and on what a team is allowed to do with a case that only fails in a suite. The dangerous outcome is a standing re-run policy that converts a defect into a permanent tax.

## Why residue exists at all A **driver session** carries condition between the cases that share it. That is exactly what makes it cheap to reuse and exactly what makes it dangerous. When a case ends, the session is not automatically back where it started: it is wherever the last case left it. Reusing one across cases therefore turns an implicit question into a design obligation — *what does the next case need to be true, and who makes it true?* Note the boundary: records the previous case created inside the system under test are a separate concern with its own handling. What follows is only the condition held by, or set through, the connection itself. ## What has to be reset - **Client-side stored data** the application keeps for the current user — anything persisted through the session that changes what the application shows on first load. - **Current location.** The session is still parked on whatever screen or resource the last case ended on. A case that assumes it starts from the entry point is asserting on someone else's page. - **Open overlays and dialogs.** A modal, a confirmation prompt or a notification banner left open silently intercepts the next case's first interaction. - **Permission and consent decisions** already granted or dismissed in this session, which change whether a prompt appears at all. - **Viewport size, zoom and display density** that one case changed to test a narrow layout. - **Connection-level settings applied to the session for one case** — a shortened wait budget, a request-interception rule, an injected header, a simulated slow network — all of which persist until something removes them. - **Accumulated in-page listeners, timers and background polling** left running by the last case, which keep firing under the next one. - **Captured logs and event buffers**, which otherwise attach the previous case's errors to this case's failure artefact. ## The failure class it produces Missing a reset does not produce a clean, honest failure. It produces an **order-dependent** one, and it has two recognisable shapes: 1. **Passes in the suite, fails alone.** The case was silently relying on a condition an earlier case established. Run it by itself and the precondition is gone. 2. **Passes alone, fails in the suite.** The case is correct, and an earlier case left something behind that breaks it. Both shapes share one signature: **the case that goes red is not the case that is wrong.** That is what makes this expensive. The engineer who owns the failing case reads a stack of evidence about their own feature, finds nothing, re-runs, and sometimes gets a pass — after which the case is labelled intermittent and quietly re-run on every failure. The defect has now been converted into a permanent tax. | Symptom | Reused-session residue | Genuine product defect | |---|---|---| | Fails only after a particular other case | very likely | rare | | Reproduces when run alone | no | yes | | Fails at the first interaction, before the case's own subject | very likely | rare | | Same failure on every machine and every order | no | yes | ## Reset in place, or discard and recreate Not everything can be reset. Some condition is reachable and cheap to clear; some lives on the far side of the connection where the test has no reliable handle on it. | Cheap to reset in place | Better to discard the session | |---|---| | Stored client data and current location | A session that has already failed once | | Viewport size and display settings | Wait budgets and interception rules layered up over many cases | | Injected headers and interception rules you added | Anything whose current condition you cannot enumerate | The rule of thumb is honest and short: **if you cannot enumerate what the session is carrying, you cannot reset it — recreate it.** A reset you cannot list is a reset you cannot review, and it will be wrong the first time someone adds a case that touches something new. ## Make the reset provable, not assumed Two habits turn this from a hope into a check: - **Assert the starting condition rather than assuming it.** Let the shared preparation step verify the two or three facts every case in the group depends on — the session is at the entry point, no overlay is open, stored client data is empty — and fail loudly with a message that says *the previous case left this behind*, not *element not found*. - **Run the suite in a shuffled order on a schedule.** Order dependence is invisible in a fixed order and obvious in a random one. A periodic shuffled run is the cheapest detector of residue that exists, and the failures it produces name the pairing directly when each case records which case preceded it.

  • How would you find which earlier case is leaving the residue that breaks a later one?
    Record, for every case, the case that ran immediately before it on the same session, so a failure report names the pair. Then bisect: run the suspect predecessor plus the failing case alone. Shuffled runs surface far more pairs than a fixed order, which by definition hides every dependency it satisfies.
  • Why is asserting the starting condition better than simply clearing everything and hoping?
    A clear step that silently fails is indistinguishable from one that worked. An assertion turns that into a loud failure with a message naming the previous case, at the moment the reset stopped being sufficient — typically when someone adds a case that touches something the reset list never covered.
  • When should a reset be abandoned in favour of discarding the session?
    When you cannot enumerate what the session holds, when settings have been layered up across many cases, or when the case has already failed. A failed case is the most likely to have left something unusual behind, so retiring its session removes the largest single source of contamination for one extra acquisition.

saying these in an interview costs you the question

  • Believes ending a case automatically returns the session to its starting condition
  • Resets only stored client data and forgets location and open overlays
  • Labels order-dependent failures intermittent and re-runs them
  • Cannot say which per-case connection settings persist after the case ends
  • Assumes a reset step worked because it did not throw