Write tests that catch the profile bugs
advanced Test design Challenge 21 of 22
The Acme profile page lets a signed-in user change their display name. Its only test fills the field, clicks Save changes and checks the toast. Three versions of the page have bugs planted in them, and that test passes on all three. Write tests that catch every one, while still passing on the working app.
How the page should behave
- When the page opens, the Display name field shows the current name,
Ada. - Saving a new name shows a status message reading “Profile saved”, and the new name is still there after a reload.
- Saving an empty name shows an alert reading “Display name is required” and leaves the stored name unchanged.
Server data resets at the start of each test, so every test begins with the name Ada.
Requirements
- All your tests pass on the working app.
- Each buggy version makes at least one of your tests fail.
- Use the preview of the demo app to explore the page before you write locators.
Expected output
Every test passes on the working app, and each buggy version makes at least one test fail.
Scenarios (4)
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
- ○Bug: current name is not loaded into the form · must catch
- ○Bug: save shows a toast but nothing is stored · must catch
- ○Bug: an empty name is accepted · must catch
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
- Explain Browser, BrowserContext and Page in Playwright. Why do contexts matter for test isolation?
- How do Playwright fixtures work? Build a custom fixture with test.extend.
- How do you avoid logging in through the UI in every Playwright test?
- How do you mock or modify network responses in Playwright, and when should you?