Playwright Testing Mock Interview: 20 Questions in 50 Minutes

Official packages exist for React, Vue and Svelte, named like @playwright/experimental-ct-react and @playwright/experimental-ct-vue. Each package provides the mount fixture and hooks in the style of its framework, such as slots and events for Vue. Support has changed between versions and the feature is experimental, so check the current docs and pin the package version alongside @playwright/test.

page is a fresh tab for each test. context is the isolated browser context that owns the page, with its own cookies and storage. browser is the shared browser instance for the worker. request is an APIRequestContext for HTTP calls. You ask for them by name in the test function, and Playwright creates and cleans them up automatically.

getByRole finds elements by their ARIA role and accessible name, the same way screen readers and users see the page. For example getByRole('button', { name: 'Save' }) keeps working when CSS classes or DOM structure change. It also pushes the team towards accessible markup. The trade-off is that badly built components without proper roles may need a test id instead.

Run the tests with npx playwright test --update-snapshots, optionally filtered to the affected files or a tag. Playwright rewrites the baselines with the new images. Newer versions also accept modes such as --update-snapshots=changed or missing so only the needed files are touched. Always look at the diff in the pull request before merging, because blindly updating hides real regressions.

Create a worker-scoped fixture that calls request.newContext with baseURL and an auth header, or logs in through the API and keeps the cookies. Pass it to use, and dispose it after use returns. Every test in that worker gets the same ready context, so login happens once per worker. Do not store per-test data on it, or tests start depending on each other.

Reusable setup/teardown units injected into tests (page, context, request). You can extend test with custom fixtures such as loggedInPage.

ctViteConfig is an option in the use block of playwright-ct.config.ts that passes extra Vite settings to the component bundle. You need it when the app relies on path aliases, plugins, environment defines or special asset handling that Playwright's default Vite setup does not know about. A typical case is adding resolve.alias so imports like @/components work in tests.

setInputFiles on the input for uploads; for downloads wait on page.waitForEvent('download') and save or inspect the file.

testInfo is passed as the second argument to tests and hooks. It gives the test title, project name, retry number, status and output path. You can attach files, add annotations, change the timeout with testInfo.setTimeout, or skip conditionally. For example, attach extra logs only when testInfo.status differs from testInfo.expectedStatus.

Check that the route is registered before the request is sent, usually before goto. Compare the pattern with the real URL in the trace network tab, including query strings and host. Make sure a service worker is not handling the request, and set serviceWorkers: 'block' if it is. Also check that another handler is not matching first or the route was not removed.

Make baseURL come from an environment variable, such as process.env.BASE_URL, with a default for local runs. In the pipeline, wait for the preview deployment to be ready, read its URL from the deployment step and pass it to the test job. Add a quick health check request first, so a failed deployment is reported clearly instead of as hundreds of test failures.

Set a written priority order: role with name, then label, placeholder or text, then test id, and CSS or XPath only as a last resort. Agree with developers to add data-testid on complex widgets. Keep locators inside page objects so a change is fixed in one place. Add a lint rule or review check against long CSS chains and nth-child selectors.

Cover happy path, validation errors, auth and permissions, boundary values, idempotency, schema, performance and data cleanup.

Block it in tests with context.route on its domain and route.abort, or fulfill it with an empty script. Analytics is not what you are testing, and blocking it removes delays and random network errors. If tracking events matter, write a few separate tests that capture the requests with waitForRequest and assert their parameters.

Situation: I joined a team whose Playwright suite was in TypeScript while I knew only basic JavaScript. Task: become productive in two weeks. Action: I studied types, interfaces and generics in the evenings, read the team's page objects, and fixed small compiler errors as practice. Result: by week three I was writing new tests and reviewing simple pull requests.

Situation: a teammate proposed mocking all APIs to make the suite fast. Task: keep speed without losing integration coverage. Action: I showed two recent bugs caused by API changes that mocks would have hidden and proposed mocking only third parties and error states, keeping ten real end-to-end journeys. Result: the team agreed and the next contract change was caught before release.

Situation: a developer said a failing checkout test was flaky and asked to skip it before release. Task: decide based on evidence. Action: I shared the trace showing the total stayed wrong after a coupon was removed and reproduced it manually. Result: we agreed it was a real bug, it was fixed before release, and we started reviewing traces together.

Situation: during my internship a login test failed only in CI and I could not reproduce it. Task: find the cause. Action: I enabled trace on first retry, downloaded the trace and stepped through the actions, and saw a cookie banner covering the sign-in button in the CI viewport. Result: I added a step to accept the banner, the test became stable, and I shared the method with my team.