An end-to-end suite reuses one saved session for a single shared account across all tests, and the tests run in parallel across several workers. What failures does sharing that one identity cause, and how do you keep programmatic login while restoring isolation?
answer
- fresh context is not a fresh account
- two tests, one identity, one server session
- who logs out breaks everyone
- one identity per role, per worker
- destructive tests need throwaway accounts
basics
~20 sParallel tests on one account fight over account-scoped state and can invalidate each other's session — a logout, password change or settings edit in one worker breaks another. Give each worker and each role its own account and its own saved session.
solid answer
~50 sOne saved session means one identity, and every worker mutates the same account concurrently. Two classes of failure follow. First, **shared account state**: one test flips a preference, marks notifications read or renames the profile, and another test asserting on that state fails depending on ordering. Second, **session invalidation**: a test that signs out, rotates a password, or hits "log out of all devices" kills a token other workers are still using, producing unexplained redirects to the login page. The fix is a matrix of identities rather than one — an account per role, and for mutation-heavy suites an account per worker (derived from the worker index) — each with its own saved session created once at setup. Where a test must mutate account-level settings, give it a dedicated throwaway account instead of borrowing the shared one.
go deeper
Know that a saved session represents a real user account, so two tests using it are acting as the same person on the server, not as two independent users.
Explain both failure modes concretely — account-scoped state mutated by a parallel test, and one test invalidating a session others still hold — and how per-role plus per-worker accounts remove them.
Demonstrate diagnosis: recognise ordering-dependent failures and mid-run 401 bursts as identity contention rather than timing, and isolate the destructive tests that revoke credentials onto disposable accounts.
Own the identity model as infrastructure: how accounts are provisioned and pooled per environment, how the matrix stays bounded as parallelism and roles grow, and where account partitioning stops helping because the contention is over shared global data.
## What one shared session actually shares A saved storage state is not just a speed trick — it is an *identity*. Restoring the same state in ten parallel browser contexts does not give you ten independent users; it gives you ten browsers logged in as the same person, hitting the same server-side account concurrently. Isolation at the browser level (fresh context, no shared cookies between tests) is not isolation at the account level. That distinction is what interviewers are probing. Candidates who have only read about storage state say "each test gets a fresh context, so they're isolated". Candidates who have run a real suite know the failures that follow. ## Failure mode one: account-scoped state Anything the server stores *per user* is now shared mutable state across parallel tests: - A test toggles a preference (dark mode, default currency, a feature opt-in) and another test asserts the old value. - A test marks the notification list read; a test asserting "3 unread" fails. - A test adds an item to the account's cart, watchlist or draft; a test asserting an empty list fails. - Onboarding or "first time you see this" tooltips get dismissed by one test and are missing for another. The signature of this failure is ordering-dependence: green alone, red in the suite; green at one worker count, red at another; failures that move around between runs. It is easy to misdiagnose as a timing problem and "fix" with a wait, which does nothing. ## Failure mode two: session invalidation Some actions do not merely change data, they revoke credentials: - An explicit sign-out, if the backend invalidates the server-side session rather than only clearing the cookie. - A password change or a "sign out everywhere" control. - A backend that permits only one active session per user, or that rotates a refresh token and rejects reuse of the previous one. When one worker triggers any of these, other workers holding the same session start getting 401s and redirects to the login page mid-test. The failures land in whatever test happened to be running, so they look random and unrelated to the culprit. This is why a suite can pass for weeks and then become "flaky" the day someone adds a logout test. ## The fix: an identity matrix, not one identity The cure keeps programmatic login and multiplies identities along two axes. **By role.** Most apps have distinct permission levels — admin, editor, viewer. Create one account per role and one saved session per role, produced once at the start of the run. Tests declare which role they need and load the matching state. This is a coverage win as well as an isolation one: role-specific tests stop needing bespoke setup. **By worker.** For suites where tests mutate account-scoped state, add a second axis: `editor-w0`, `editor-w1`, … one per parallel worker. Most runners expose a worker or process index; deriving the account from it guarantees no two concurrently-running tests share an identity, while keeping the number of accounts bounded by parallelism rather than by test count. ```ts const index = Number(process.env.TEST_WORKER_INDEX ?? 0); const account = `editor-w${index}@example.com`; ``` **By test, for the destructive ones.** A test that changes a password, deletes the account, or revokes all sessions must not borrow a pooled identity at all. Provision a throwaway account for it, or mark it to run serially outside the pool. These tests are rare, so the cost is small; the alternative is a suite that poisons itself. ## Setup cost and where it lives The obvious objection is that N roles times M workers means many logins. In practice it does not matter: authentication happens once per identity per run in a setup phase, each producing a small state file, and the tests themselves only restore. If provisioning accounts is expensive, keep a stable pool of pre-created accounts in the environment and check them out by index rather than creating them per run — the pool is a fixture, not a per-test cost. Store the produced session artefacts in a gitignored directory, never in version control: they are credentials, and a stale one is worse than none. ## What this does not fix Account partitioning solves *identity* contention. It does not solve contention over globally shared resources — the same product record edited by two tests, a singleton admin setting, a shared external sandbox with rate limits. Those need their own isolation strategy. Be precise in an interview about which problem you are solving: "one account per worker" is an answer about sessions and account-scoped state, not a universal isolation cure.
- How would you recognise this problem from a failure report rather than guessing at it?Look for ordering-dependence: the test passes in isolation, fails in a full run, and the failure moves as parallelism changes. Session-invalidation cases show a mid-test redirect to the login page or a burst of 401s across unrelated tests at the same timestamp — correlate that timestamp with whichever test performs a sign-out or credential change.
- A test must verify "sign out of all devices". How do you stop it wrecking the rest of the run?Give it its own disposable account created for that test, so revoking every session affects nothing else. If provisioning is not possible, pin it to a reserved account excluded from the shared pool and run it outside the parallel group. Never let it borrow a pooled identity — its whole purpose is to invalidate sessions.
- Does creating one account per worker scale as the suite grows?Yes, because the account count is bounded by the worker count, not the test count — doubling the tests adds no accounts. What grows is the role axis, and that is bounded by the app's permission model. The cost that does grow is provisioning time at setup, which is why teams often keep a stable pre-seeded pool and check accounts out by index.
saying these in an interview costs you the question
- Claims a fresh browser context alone guarantees test isolation
- Reuses one admin account for the entire parallel suite
- Treats ordering-dependent failures as a timing problem to wait out
- Lets a logout test run against the shared pooled account
- Creates a brand-new account inside every single test