Your Playwright test is green. Your checkout is broken

In many codebases, a Playwright test often appears: "test (places an order, async ({ page })) => { await page.goto('/'); await page.getByLabel('Name').fill('Ada'); await page.getByRole('button',{name:'Place order'}).click(); await expect(page.getByRole('status')).toContainText('Order placed'); }". This test passes despite the order API returning a 500 error and no data being saved. The test fails to detect the issue because the page displays a success message even if the server does not agree.

Frontend patterns like optimistic UI, error swallowing, and checking response arrival, but not success, lead to this problem. These patterns display a success message, such as "Order placed", while the order never exists in the system.

To catch this issue, three methods can be used: fixing the response, reading the data back, and implementing a safety net for the entire suite.

The first fix involves asserting on the response, waiting for the request triggered by the click, and checking its status. This ensures the exact endpoint and status are verified, but requires remembering this check on every test that writes data.

The second approach reads the data back using a 201 status code from the API. It checks if the order was stored by calling a list endpoint and verifying if the order with name 'Ada' exists. This method catches when the server answers 200 and silently drops the write.

Finally, the third option is a safety net for the entire suite. By using an automatic fixture, any test that encounters a server error (status code 500) will fail. This approach protects all tests, not just the ones added with the fix.