Interview Corner

A: API mocking means intercepting HTTP requests made by the browser and returning fake responses instead of letting them reach the real server. In Playwright, we use page.route() to intercept and route.fulfill() to return custom responses. It is important because it makes tests faster (no network latency), more reliable (no backend dependency), and enables testing edge cases like error states, empty data, and slow responses that are hard to reproduce with a real API.

A: page.route() is an interceptor -- it catches requests and lets you modify, fulfill, or abort them. The request does not proceed until your handler decides what to do. page.on("request") is a listener -- it observes requests passively without modifying them. The request proceeds normally. Use route() when you want to mock or block. Use on("request") when you want to monitor or log.

A: I would mock the user profile API to return different roles. For example, mock /api/user to return { role: "admin" } in one test and { role: "viewer" } in another. Then verify that admin sees the admin panel, edit buttons, and delete buttons, while viewer only sees read-only content. This way I test all role-based UI without needing multiple real user accounts.

A: HAR stands for HTTP Archive. It is a JSON file that records all HTTP requests and responses during a browser session. In Playwright, you record a HAR with page.routeFromHAR("file.har", { update: true }), then replay it with page.routeFromHAR("file.har"). It is useful when you have complex flows with many API calls and you want realistic mock data without writing it by hand.

A: I use Playwright storageState feature. I create a setup project that logs in once and saves the auth state (cookies, localStorage) to a JSON file using page.context().storageState({ path: "auth.json" }). Then in playwright.config.ts, I configure all test projects to use this storageState file. Every test starts already authenticated. This saves 5-10 seconds per test.

A: Two options. First, I would use page.waitForResponse() to wait for the specific API call to finish before asserting on the UI. This replaces any hardcoded waits. Second, if the flakiness is caused by the real API being unreliable, I would mock it with page.route() and route.fulfill() so the test does not depend on the real API at all. The choice depends on whether this is a unit-level UI test (mock it) or an integration test (wait for it properly).

A: route.abort() kills the request -- the browser gets a network error, as if the server is unreachable. Use it to test offline scenarios or block unwanted resources. route.fulfill() returns a custom response you define -- status, headers, body. The real server is never contacted. Use it for mocking. route.continue() lets the request go to the real server, but you can modify headers, URL, or method on the way out. Use it to add auth headers or redirect requests.

A: I follow a testing pyramid approach. Most tests (80%) are mocked -- they test UI logic, error handling, edge cases, and rendering with controlled data. These run fast and are reliable. A smaller set (15%) are integration tests that hit the real staging API to verify the actual data flow works end-to-end. And a few (5%) are smoke tests in production-like environments. The key principle: mock for speed and coverage, use real APIs for confidence.