Basic Playwright questions
1. What is Playwright?
An open-source browser automation and testing framework from Microsoft that drives Chromium, Firefox and WebKit through one API, with official support for TypeScript/JavaScript, Python, Java and .NET.
2. What is auto-waiting?
Before acting, Playwright waits for the element to be attached, visible, stable, enabled and able to receive events. Web-first assertions like expect(locator).toBeVisible() also retry until a timeout, removing most manual sleeps.
3. Which locators are recommended?
User-facing locators: getByRole, getByLabel, getByPlaceholder, getByText and getByTestId. They match how users perceive the page and survive markup changes better than CSS or XPath.
Intermediate Playwright questions
4. What are fixtures in Playwright Test?
Fixtures provide each test with ready objects such as page, context and request, and can be extended with your own (for example a logged-in page or test data) with setup and teardown handled automatically.
5. How do you reuse login across tests?
Log in once in a setup project, save the session with context.storageState({ path }), and configure other projects with use: { storageState } so tests start already authenticated.
6. How do you test APIs with Playwright?
Use the request fixture or request.newContext() to send GET, POST and other calls, then assert status and JSON. API calls are also used to create test data quickly before UI steps.
7. How do you mock network responses?
page.route(urlPattern, handler) intercepts requests; the handler can fulfill with mock JSON, modify the request or abort it. This makes UI tests independent of slow or unstable back ends.
Advanced Playwright questions
8. How do you debug a failing test?
Run with --debug or the UI mode, use page.pause(), and enable trace: 'on-first-retry' to open the trace viewer with DOM snapshots, network calls and console logs for each step. Screenshots and videos can be kept on failure.
9. How does Playwright run tests in parallel?
Test files run in parallel worker processes, each test getting a fresh, isolated browser context. Use fullyParallel, workers and sharding (--shard=1/4) in CI to split large suites across machines.
10. How do you reduce flaky tests?
Use role-based locators and web-first assertions, avoid fixed timeouts, isolate test data, mock unstable third parties, wait for specific responses instead of networkidle, and investigate retries with traces instead of ignoring them.
Want to practise these with a trainer? APEX live batches include mock interviews, real projects and placement support. See upcoming batches.