18 Playwright Component Testing and Page Model Interview Scenarios

Framework interviews should uncover where a candidate places boundaries. A component test, page model, fixture, and spec each own different work. When those responsibilities blur, tests hide setup, duplicate assertions, and couple every change to one oversized abstraction.

These scenarios ask you to decide what is being tested, which browser surface is required, who creates each dependency, and where the result is asserted. Senior answers should discuss both maintainability and diagnostic quality, because an elegant API that produces opaque failures is not a successful framework.

Start with the Test Boundary

The official Playwright component testing guide describes components running in a real browser while tests execute in Node.js, including a boundary on the objects that can cross between them. Before designing a model, decide whether the risk belongs to a component, a page, a multi-page journey, or an external integration.

The most reusable abstraction is not always the largest one. Prefer the smallest vocabulary that represents stable product behavior and still lets a failed report identify the broken contract.

Component Testing Decisions

1. Why would you test a date-picker component outside the full booking journey?

The component has dense state transitions such as month navigation, disabled dates, keyboard movement, and selected-range styling. Mounting it with controlled props isolates those behaviors in a real browser and yields faster, more focused diagnosis. I would retain an end-to-end booking test for integration with availability and pricing. Component coverage reduces duplication; it does not prove that the deployed journey wires every dependency correctly.

2. How would you decide whether a component test is too isolated?

I would ask whether the risk depends on router state, application providers, server behavior, global styles, or another component's coordination. If the test replaces most of the production environment with custom wrappers, it may validate the wrapper instead of the product. Add only the providers needed to represent a real state, and move the scenario upward when the essential contract is interaction between subsystems rather than component rendering.

3. Why do complex live objects require a wrapper at the component-test boundary?

The test runs in Node.js while the component runs in the browser, so arbitrary live objects and synchronous callbacks cannot simply cross that boundary as if they shared one runtime. I would create a test story or wrapper that converts a browser object into serializable input or a simple event. The wrapper should remain thin and production-faithful; building a second implementation for tests creates false confidence.

Page Model Design

4. When is a page model more useful than direct locators in a spec?

I would introduce one when several scenarios share stable domain interactions such as submitting a transfer, filtering invoices, or reading a checkout summary. The model names those actions and centralizes locator knowledge. For a short one-off test, direct role locators may be clearer. Abstraction should reduce meaningful change radius, not satisfy a rule that every page needs a class.

5. Why should page-model methods describe user intent?

A method named submitRefund communicates a product operation and can contain the required click plus stable readiness boundary. A method named clickThirdButton merely hides mechanics and makes the spec harder to understand. I would keep methods cohesive, avoid long multi-page scripts inside one call, and return or expose the next domain surface when a workflow crosses ownership boundaries.

6. How should locators be exposed from a page model?

Keep implementation locators private or readonly when callers should not depend on their structure, and expose focused domain surfaces when a spec needs a scenario-specific assertion. Returning every raw locator makes the class a selector bucket; hiding every observable makes custom assertions awkward. I would choose a small public API and let TypeScript show what consumers are allowed to rely on.

import { test as base, expect, type Locator, type Page } from '@playwright/test'

class CheckoutPage {
  readonly summary: Locator

  constructor(private readonly page: Page) {
    this.summary = page.getByTestId('order-summary')
  }

  async open(orderId: string): Promise<void> {
    await this.page.goto('/checkout/' + encodeURIComponent(orderId))
    await expect(this.summary).toBeVisible()
  }

  async submitPayment(): Promise<void> {
    await this.page.getByRole('button', { name: 'Pay now' }).click()
  }
}

type Fixtures = { checkout: CheckoutPage }

export const test = base.extend<Fixtures>({
  checkout: async ({ page }, use) => {
    await use(new CheckoutPage(page))
  },
})

7. Why is one application-wide page object usually difficult to maintain?

It accumulates unrelated locators, actions, state assumptions, and owners. A change in checkout can force edits in a class also used by account and search tests, while method names lose domain meaning. I would split around cohesive pages or reusable components and compose them where journeys meet. Too many tiny wrappers can also add ceremony, so boundaries should follow stable product ownership rather than every DOM container.

Fixtures and Composition

8. Why create a page model through a fixture?

The fixture declares that the model depends on the current test's page, constructs it only when requested, and gives the runner a clear lifecycle. It can also inject typed options or domain clients without hidden imports. I would avoid automatic navigation in the constructor; setup that changes state should remain an explicit fixture step or model method so reports show where preparation failed.

9. Why should a page model normally remain test-scoped?

Its locators resolve against a page whose cookies, navigation, and DOM belong to one test context. Worker-scoping the wrapper would either violate fixture dependencies or tempt tests to share browser state. Construction is cheap, so there is little performance value in sharing it. Expensive backend accounts or immutable catalogs can have separate lifetimes without extending the page model beyond its valid owner.

10. How would you compose framework fixtures from different domain teams?

I would publish deliberate fixture modules with unique names and stable types, then merge them at one supported test entry point. Specs import that entry point rather than selecting incompatible base tests. Composition should remain demand-driven: requesting a catalog model must not silently provision payments. I would add contract tests for fixture setup and teardown because TypeScript catches name and shape issues but not lifecycle side effects.

11. Why are automatic fixtures a poor default for login and navigation?

They hide preconditions from the test signature, run for unrelated cases, and make setup failure look detached from scenario intent. I would reserve automatic fixtures for cheap universal diagnostics or policy enforcement. Authentication can be an explicit storage-state project or requested fixture, and navigation should be visible in the scenario or a clearly named setup dependency. Convenience should not erase who owns state.

Assertion Ownership

12. When should a page-model method contain an assertion?

It can assert a stable invariant required to complete its own operation, such as the checkout summary becoming ready after opening the page. Scenario-specific outcomes, such as a fraud warning for one card, should remain in the spec. I would avoid methods that perform many soft assertions and return despite failure. Reusable assertions should have focused names and reports that identify the domain contract they protect.

13. How would you prevent component and end-to-end tests from asserting the same details?

I would assign component behavior and variants to component tests, integration wiring to a smaller set of page or journey tests, and business completion to end-to-end assertions. The journey may assert that the date picker opens and the selected range reaches pricing, without rechecking every keyboard path. A coverage map organized by risk exposes duplication and gaps better than comparing test counts.

14. Why should accessible roles influence model and component APIs?

Role and accessible-name locators align automation with user-visible semantics and make accessibility regressions observable. A model method that locates a submit control by role is more meaningful than a CSS implementation chain. I would still use explicit test IDs for contracts with no reliable user-facing identifier. The framework should encourage good semantics without turning locator policy into an inflexible ban on practical test hooks.

Maintenance and Failure Scenarios

15. How would you respond when a product redesign breaks many model methods?

I would separate intentional workflow changes from locator churn. If the product vocabulary changed, update the model API and its consumers deliberately rather than preserving obsolete methods behind aliases forever. If only markup changed, stable semantic locators should constrain the repair. I would run representative model contract tests and review failure messages so the redesign does not leave broad helpers that conceal new intermediate states.

16. Why can a generic waitForReady method become dangerous?

Different pages and actions have different readiness contracts. A helper that waits for a spinner to disappear may pass before data is usable, or hang when the spinner is absent by design. I would name readiness after the domain state, such as waitForInvoiceRows, and assert an observable outcome. Shared low-level waiting belongs in a utility only when semantics and failure evidence are genuinely identical.

17. How would you review a model that makes every action retryable?

I would reject blanket retries around clicks or workflows because repeated actions can create duplicate orders, payments, or messages. Playwright already handles actionability and web-first assertions. If an operation is eventually consistent, retry a safe observation, not the mutation. The author must identify the transient boundary and prove idempotency. Generic resilience can turn a clear product defect into corrupted test state.

18. How would you defend the framework architecture to a senior panel?

I would show the risk-based test layers, model boundaries, fixture graph, public APIs, assertion ownership, and expected change radius. Then I would walk through one setup failure and one product failure to demonstrate diagnostic quality. Metrics should include maintenance and flake patterns, not only reuse. The design succeeds when teams can extend their domain without importing hidden state or editing a central all-knowing class.

Framework Review Checklist

• Choose component, page, or journey scope from the product risk.
• Keep browser and Node.js boundaries explicit in component tests.
• Add models for stable domain vocabulary, not compulsory wrapping.
• Give fixtures visible dependencies, valid scopes, and clear teardown.
• Keep scenario-specific outcomes readable in the spec.
• Retry observations only when repeated execution is safe.
• Review change radius and failure evidence alongside code reuse.

Build Boundaries That Explain Failures

Close the interview by assigning each responsibility: the component test owns focused browser behavior, the model owns stable interaction vocabulary, the fixture owns construction and lifetime, and the spec owns the scenario outcome. Then explain the tradeoff that made you reject a broader abstraction. A maintainable Playwright framework is one where product changes have a predictable radius and failures still tell engineers what broke.