Cross-browser, mobile web and responsive testing
Playwright drives three browser engines: Chromium (Chrome, Edge), Firefox (Gecko) and WebKit (Safari). They're managed through the projects matrix — the same test set runs across configurations.
An important distinction: Playwright's WebKit is not real Safari — it's a build of the same open-source engine. It catches most of the differences but not everything Safari-specific (certain iOS limitations, Apple's own additions). Knowing this is worth points in an interview.
The strategy question — which browsers do you run? The answer comes from analytics, not from personal preference:
- Look at the real user distribution (Google Analytics or similar)
- If Firefox is 2% of traffic, running full regression there is waste — a smoke set is enough
- The typical model: full suite on Chromium for every PR; Firefox + WebKit smoke/critical nightly
- This covers the real risk without tripling CI time
Device emulation — the devices catalogue provides ready profiles: devices['iPhone 14'], devices['Pixel 7']. A profile sets several things at once: viewport size, deviceScaleFactor, user agent, the isMobile flag and `hasTouch` — so tap() works and hover stops behaving as it does on desktop.
Responsive testing is broader and often confused with device emulation: here the goal is that the layout behaves correctly across breakpoints. The practical approach: a few characteristic widths (e.g. 375, 768, 1280, 1920) and, at each, checking the elements whose behaviour actually differs — is the hamburger menu shown, does the table switch to card view, is the sticky bar in place.
An important nuance: page.setViewportSize() changes size only — touch, user agent and isMobile stay as they were. So claiming "I tested mobile" after changing the viewport alone is wrong; test.use({ ...devices['iPhone 14'] }) gives a fuller emulation.
The limits of emulation — the part you must state in an interview. Emulation does not catch: real device performance (slowness on a weak CPU), real touch gestures and their precision, iOS Safari's idiosyncrasies, the device keyboard, network quality, battery/memory constraints. On high-risk mobile products a real-device cloud (BrowserStack and similar) or manual verification remains a necessary extra layer.
| Question | Caught by emulation? | Explanation |
|---|---|---|
| Does the layout collapse correctly at 375px? | Yes | Viewport + CSS breakpoints are fully emulated |
| Does the hamburger menu appear at mobile width? | Yes | Pure CSS/DOM behaviour |
| The page takes 6 seconds on a weak phone | No | Real CPU/memory limits aren't emulated (CPU throttling helps only partially) |
| Pinch-zoom and complex gestures | No | A simple tap is emulated; real multi-touch gestures are not |
| An iOS-Safari-specific bug | Partially | The WebKit engine is the same, but it isn't iOS Safari's full behaviour |
| Does the device keyboard cover the input? | No | Native keyboard behaviour is outside browser emulation |
The sentence that makes a difference in interviews: "Emulation catches CSS and layout problems, not device reality." Then give a concrete example: "at a 375px viewport the button is visible and clickable, but on a real phone it's smaller than a fingertip and users keep missing it — you only see that on a real device." An answer with a concrete example always beats a general one.