Testing with Playwright
The route
- 80 minWhat to test, and what to leave alone
Choosing the handful of paths that genuinely deserve end-to-end coverage.
You board here - 80 minSelectors that survive a redesign
Roles, then labels, then test ids — in that order, and why.
- 80 minHonest waiting
Web-first assertions, and how every sleep you delete makes the suite faster and truer.
- 80 minFixtures and data you control
Seeding and isolation, so tests pass in any order and on any machine.
- 85 minIn CI, with traces
Parallelism, sharding and retries — and reading a trace instead of re-running.
A look at the teaching
Two tests for the same button. One breaks the next time the markup moves.
// Brittle: coupled to the DOM's shape.
await page.locator('div.panel > button.btn-primary').click();
// Durable: coupled to what the person sees.
await page.getByRole('button', { name: 'Buy this course' }).click();
// Then assert on state, never on a timer.
await expect(page.getByText('Ticket issued')).toBeVisible();
If a selector would survive you rewriting the CSS, it is testing the product. If it would not, it is testing the markup — and it will fail on a day when nothing is actually broken.
Who is driving
Eszter teaches the way a good colleague explains things at a whiteboard — no jargon for its own sake, and nothing hidden behind “as you can see”.
Placeholder profile