Wait for the API, not the clock
intermediate Waits Challenge 10 of 22
The search test waits a fixed second for results. It is slow on fast runs and still flaky on a busy CI agent. Rewrite it so it waits for the search API call to finish.
Requirements
- Remove
waitForTimeout. - Use
page.waitForResponse(...)for the products search request, registered before the click that triggers it. - Check the response status.
- Assert the number of result rows with a web-first assertion such as
toHaveCount.
Expected output
The test starts waiting for the GET /api/products?q=keyboard response before clicking Search, checks its status, and asserts the row count with a retrying `toHaveCount(3)`. No fixed sleeps.
Scenarios (3)
Your tests run once against each version of the demo app. They must pass on the working app and fail on every version with a planted bug.
- ○Working app · must pass
- ○Slow API · must pass · API 1500ms
- ○Bug: search ignores the query · must catch
Checks (5)
- ○Does not use a fixed waitForTimeout
- ○Waits for the API response with waitForResponse
- ○Starts waiting for the response before clicking
- ○Checks the response status
- ○Asserts the results with a web-first assertion
example.spec.tsRuns against a live demo app
Ctrl/⌘ + Enter to run tests · your code is saved in this browser
Results
Run the tests to see results here.
Demo app
The working app. You can click around it; your tests start from a fresh copy.
Related interview questions
- What are web-first assertions, and why is expect(await locator.textContent()).toBe() an anti-pattern?
- How do you mock or modify network responses in Playwright, and when should you?
- Explain Browser, BrowserContext and Page in Playwright. Why do contexts matter for test isolation?
- How does Playwright auto-waiting work, and when is it not enough?