Make your Playwright save test prove the data changed

The problem: a convincing success screen

An agent changes a customer-edit form in an established .NET application and adds a Playwright test. The test enters a name, clicks Save, and checks the confirmation banner. That leaves an expensive blind spot: the screen can report success while the stored customer remains unchanged.

Inspect the test's network setup. Playwright can fulfill a request with a synthetic response without calling the application API. That is useful for testing UI reactions, but a mocked save response cannot establish persistence. Keep those tests; add a separate acceptance scenario that reaches the real application and test database.

Define a change that cannot pass by accident

Use a synthetic customer assigned to this test run. Seed its name as Original Customer, then submit Revised Customer through the UI. Assert the starting value first. A fixture already containing the expected final value can hide a save that does nothing.

Playwright isolates browser cookies and storage between tests. Your shared SQL Server data still needs its own isolation strategy. Allocate separate records per test attempt, including retries, and clean them up through the approved fixture mechanism. Keep external notifications in a sandbox.

Check the result outside the success response

Playwright supports API requests for checking server state after browser actions. Use an authorized read for the exact customer and tenant. Verify that this path reads committed storage rather than echoing the submitted payload or serving a write-through cache. If it cannot provide that evidence, use a narrowly scoped test-database assertion from the runner.

For a cookie-authenticated application, page.request shares the browser context's cookies. Other authentication schemes need explicit setup. Do not add a public diagnostic endpoint just to make the test convenient.

Check the displayed value after reload as additional evidence. For asynchronous saves, use bounded expect.poll around a read-only observation, with a timeout taken from the agreed business contract. Never put the save action inside the polling callback: retries would change the scenario.

Give the agent a bounded implementation brief

This is a proposed acceptance contract, not code executed against a customer application. Adapt it to the application's routes, authorization, and persistence model.

Scenario SAVE-01: an authorized customer edit persists.
1. Allocate a unique synthetic customer for this attempt.
2. Independently verify its stored name is Original Customer.
3. In the browser, change it to Revised Customer and save once.
4. Verify the exact customer's committed name is Revised Customer.
5. Reload the page and verify the displayed name matches.
6. Clean up the fixture even if an assertion fails.
Do not mock the save or verification read in this scenario.
Do not alter application behavior, CI rules, or existing assertions.
Report assumptions, commands run, and any unexecuted checks.

Prove that the harness catches the defect

In a disposable test build, deliberately suppress this write while preserving the success response. SAVE-01 must fail at the stored-value assertion. Restore the write, reset the fixture, and require a pass. Record both results and their commits; these are acceptance checks to perform, not reported results.

Use the linked agent work kit to scope the task and the Playwright harness playbook to define ownership and merge controls. For an implementation engagement, the $4,000 AI QA Launch Sprint covers one agreed critical workflow over two weeks, including fixtures, regression checks, failure traces, and CI evidence. Required checks depend on configured repository protections and agent permissions without bypass access.