Page Object Model

The Page Object Model (POM) puts everything a test needs to know about one page, its locators and the actions a user can take there, into a single class. Tests then read like the user journey (loginPage.signIn(user)), and when the markup changes you fix one class instead of every test.

A minimal example (Playwright, TypeScript)

import { type Page, type Locator } from '@playwright/test';

export class LoginPage {
  readonly email: Locator;
  readonly password: Locator;
  readonly submit: Locator;

  constructor(private readonly page: Page) {
    this.email = page.getByLabel('Email');
    this.password = page.getByLabel('Password');
    this.submit = page.getByRole('button', { name: 'Sign in' });
  }

  async goto() {
    await this.page.goto('/login');
  }

  async signIn(email: string, password: string) {
    await this.email.fill(email);
    await this.password.fill(password);
    await this.submit.click();
  }
}

Rules that keep page objects useful

• No assertions inside page objects, except checks that the page itself loaded. The test decides what “correct” means.
• Return the next page object from actions that navigate, or return nothing. Avoid returning raw element handles.
• Model components, not just pages. A header, a data table or a date picker that appears on many pages deserves its own class.
• Keep them thin. Business rules, test data and API calls belong in other layers, such as fixtures and API clients.

Common criticism

Large page objects turn into “god classes” with dozens of methods. Splitting by component, and using fixtures to create page objects for each test, keeps them small. Some teams prefer the Screenplay pattern for very large suites, but POM remains the most common structure in Selenium and Playwright frameworks and the one interviewers expect you to explain.