Question 1

The payment flow has a 3D Secure iframe. How do you test that flow?

Accepted Answer

The technical part is short: an iframe is a separate document, so I switch context with page.frameLocator('iframe[title="3D Secure"]'), work with ordinary locators inside, and go back to the parent page for assertions once I'm out. I locate the frame by its title/name attribute — nth(0) is brittle because analytics iframes may also be on the page. But I don't stop there, because the real question is deeper: 3DS is a third-party system. So I describe a layered approach — one or two real E2E tests against the sandbox (successful payment), with the remaining variations (wrong code, timeout, cancellation) verified deterministically via mocks. The bank sandbox going down must not break our CI. That addition is what separates middle from senior here.

Question 2

How do you test file upload and download?

Accepted Answer

Upload: for a plain <input type="file"> I use setInputFiles('fixtures/files/id-card.pdf') — no OS dialog, so headless CI is fine. If a custom button hides the input, I intercept page.waitForEvent('filechooser'). Fixture files are kept small in the repo. Cases to cover: a valid file, a disallowed format, a file over the size limit, an empty selection, multiple files. Download: I arm the wait before the click, then verify both the NAME (suggestedFilename()) and the CONTENT — merely asserting "a download started" is weak, since an empty or wrong file downloads just as happily. I add checks like a non-zero PDF size, or the expected row count and headers in a CSV. One practical closing note: deep verification of the file's inner content (values in a table inside a PDF) is not a UI test's job — a unit/API test of the generating service does it better. That "pick the right level" reflex strengthens the answer.

Question 3

Explain the difference between page, context and browser.

Accepted Answer

The hierarchy: browser is the launched browser process (heavy, opened once); context is an isolated profile inside it — its own cookies, localStorage, permissions, geolocation; page is a single tab inside a context. The key practical consequence: isolation lives at the context level. Playwright gives each test a fresh context by default — which is exactly why tests can't see each other's sessions and can run in parallel. It's also why creating a context is cheap: no new browser process starts. When I call newContext() explicitly: (1) when one test needs two different users; (2) when a different storageState (role) is required; (3) when specific options — locale, timezone, permissions, viewport — must change for one test. The trap question: "do two tabs give you two users?" — no, tabs share the context's session.

Question 4

An unexpected cookie banner or modal appears mid-test and breaks tests. How do you solve it?

Accepted Answer

First I distinguish the cause, because the fix depends on it. If the banner always appears, it's simply part of the flow: I dismiss it once in setup — ideally at the state level (the consent cookie stored in storageState) or by pre-seeding the cookie when creating the context. That's faster and more stable than clicking it in every test. If the modal appears sporadically (a marketing pop-up, a survey widget), Playwright's page.addLocatorHandler() exists exactly for this: register a handler, the element gets dismissed automatically when it shows up, and the test continues. Before that API, people "solved" this with try/catch and hidden sleeps — both flakiness sources. A third option, often the most correct: disable external widgets (analytics, chat, marketing) in the test environment behind a feature flag, or cut them with route.abort(). I close with the important nuance: if the pop-up also annoys real users, it isn't a test problem — it's a product problem, and I raise it as a bug.

Task	API	Typical mistake
Ticking a checkbox	check()	click() — unticks it when already ticked
Uploading a file	setInputFiles()	Trying to drive the OS dialog with a robot
Downloading a file	waitForEvent('download') + click	Starting the wait AFTER the click
Accepting a confirm() dialog	page.once('dialog', d => d.accept())	Registering the handler after the click
Reaching an element inside an iframe	page.frameLocator(...)	Searching with a plain locator — never found
Acting as two users in one test	browser.newContext() × 2	Opening two tabs — the session is shared

Essential Playwright APIs: forms, files, dialogs, frames

📚 Sources and documentation