14. Test data, isolation and privacy

A test’s data is part of its precondition. Shared mutable records can make otherwise correct checks depend on execution order. Start with small synthetic fixtures and give each test an isolated namespace, database or transaction according to the system’s actual persistence model.

Use fictional accounts and reserved example addresses. Real documents, tokens and private saved lists do not belong in a public learning package. A trace or screenshot can retain sensitive values even when the test script itself contains none.

The worked plan gives Alice and Bob separate saved sets within a test-specific namespace. A second test receives a fresh namespace rather than inheriting the first test’s changes. This supports parallel execution without deleting a shared global fixture.

Browser-context isolation resets browser state, but it does not automatically reset server data. Coordinate the browser namespace and API setup explicitly. A fresh tab alone may share cookies, while a fresh context can still reach the same mutable server records.

The weak plan reuses one account and saved list for every worker, then clears the whole collection. One worker can erase another’s expected data. A cleanup hook does not make a dangerous global deletion safe merely because it runs after a test.

Avoid depending on wall-clock time or a random id whose failure value is never recorded. Use reproducible fixture inputs, injected time where needed and unique names only for isolation. Log enough nonsecret context to replay a failure.

Design two independent tests that each save r1 and verify one saved id. Give them separate namespaces and explain how cleanup is limited to their own data. Begin by writing the starting saved list for each test.

Then describe the behavior when both run concurrently. Optional extension: add a test that deliberately leaves its own state behind and verify that the other namespace remains unaffected. Do not run cleanup against any live account.

Step 1: Give both tests explicit empty saved lists. Step 2: Use different namespaces and scoped cleanup.

The solution assigns separate namespaces and the same empty starting list. Reusing r1 is safe because account state is partitioned by namespace. Each test can remove its own saved item without touching the other test’s data.

The verifier simulates both namespaces and checks that changing one leaves the other intact. This proves the local fixture’s isolation behavior, not every storage engine’s transaction semantics. Adapt the boundary to the real system before claiming equivalent isolation.

In interviews, distinguish browser storage isolation from server-data isolation. Explain how you would reproduce a failed parallel run without retaining private payloads. Name the exact cleanup scope rather than saying that tests reset everything.

Next, summarize test evidence for a release decision. Counts become meaningful only when their denominator, scope and unresolved risks are visible.

Optional stretch — after the core task works: Leave one namespace dirty and verify the other remains independent.

Computer practice: download the companion lab at https://applydjinn.com/typorithm/qa-lab-20261105.zip. Read its README, install the pinned tools and run the accepted examples before attempting a starter. The mobile reader preserves your reading and self-check progress; the local lab runs browser tests separately.