A browser journey test verifies an observable task across the actual rendered page, not only a function or mocked handler. Pick a small critical path: open a case directly, submit a note with keyboard controls, see either confirmed storage or a useful failure, and return to the case after refresh. Control test data and network faults so the same test can expose a delayed response, a missing API, or a duplicate retry without waiting for a real outage. Assertions should use semantic roles and visible messages where possible. A green browser journey does not prove every access rule; pair it with server contract and authorization tests. Run against a production-like build for route checks, because a development server may quietly fall back to a client shell for paths production cannot serve.
Browser Journey and Fault-Injection Tests
Working case
The inspection form appears to work in a component test. In the built site, however, a copied /cases/47 URL returns 404; another run submits a valid note but leaves the Save button enabled while the network waits, allowing a duplicate request. A critical journey starts from the direct URL, fills the labeled note field, submits once, waits for a confirmation tied to the stored record, and reloads to verify persistence. A second run intercepts the write with a delay and then a failure, checking that the draft survives and the status tells the person what happened.
Implementation boundary
import { test, expect } from "@playwright/test";
test("case note survives a direct-route refresh", async ({ page }) => {
await page.goto("/cases/47");
await page.getByRole("textbox", { name: "Inspection note" }).fill("Seal checked at 09:40");
await page.getByRole("button", { name: "Save note" }).click();
await expect(page.getByRole("status")).toContainText("Saved");
await page.reload();
await expect(page.getByText("Seal checked at 09:40")).toBeVisible();
});Cost and boundaries
A browser test starts a full runtime and can make real network and database calls, so it costs more than a unit test. Keep a short critical suite in the release gate and a broader suite on a slower schedule. Explicit waits for a known state are more reliable than fixed sleeps; test retries should not hide a reproducible defect. Isolate test records and clean them safely, or parallel runs will contaminate each other and turn the suite into noise. The snippet is an acceptance target for a project with a functioning case service, not a test claimed to run against the current content-only preview.
Failure trace
A test clicks a CSS class, sleeps for one second, and asserts that the button still exists. It passes even when the write failed or a keyboard user could not reach the control. Another test stubs the API with exactly the frontend's assumed response, so a server field rename goes unseen. Assert the meaningful status and persisted result, use semantic selectors, and keep a separate contract check against the real server. Inject one fault at a time so the failing boundary is clear.
Verification
- Open the nested route as a new visitor without first loading the homepage.
- Delay the write, submit once with the keyboard, and verify the form prevents an accidental duplicate.
- Return an error status and a dropped connection in separate runs; inspect distinct recovery messages.
Decision note
Automate the few journeys whose failure would stop a user from completing a task. Spend human review on unclear copy, focus order, and layout behavior that a locator assertion cannot fully judge.
Common Mistakes
- Do not use arbitrary sleeps as the definition of readiness.
- Do not assert only that a button exists after a write.
- Do not let a perfect mock stand in for the server contract.
Connected lessons
Integration and Verification; Signed Webhook Delivery and Replay Control; API Evolution and Compatibility Windows; Field and Lab Performance Evidence; Tests across boundaries: assert behavior, not implementation text; DOM events: enhance a working control without losing its baseline; Accessible forms: connect labels, errors, and focus; Release checks: prove the critical route and prepare a rollback.
Apply and check
Build Project: webhook contract and browser verification and review Web Development: identity and integration contracts quiz.
Further connections
Dialog Focus and Interruption Boundary; Reflow, Zoom, and Motion Preferences.