Scope browser-test failure and evidence to the behavior under test

A long browser test is trustworthy only when both its expected failure and its evidence are scoped to the behavior under test. Whole-test expected-failure markers can turn unrelated setup failures, navigation regressions, or timeouts into green results; process-global provider state and uncorrelated shared-ledger deltas can let concurrent tests satisfy or invalidate one another. Prefer exact positive assertions, per-test or namespaced provider state, and flow/test-correlated persisted-state oracles. This applies to parallel integration/E2E suites with shared harness state; it does not mean deterministic third-party stubs are inherently weak, or that a narrowly isolated known-red test has no diagnostic value.

Evidence/example — 2026-09-09

Source: read-only repository audit of e3-solutions/theft. web/e2e/forms/driver-form-acquisition-inventory.spec.ts runs 13 browser flows and places five full tests under test.fail, so any failure after the marker can satisfy the expectation rather than proving the intended acquisition-mode mismatch. web/e2e/forms/driver-form-photo-quality.spec.ts similarly wraps a long blurred-photo journey in a whole-test expected failure. Separately, web/e2e/forms/driver-document-workflows.spec.ts reads/resets exact process-global Gemini-stub request state, while the root Playwright suite runs fully parallel with six CI workers; driver-form-workflows.spec.ts uses global egress-ledger count deltas that another worker can supply. These are static concurrency risks inferred from source, not observed flaky CI failures in this audit.