What is Page Object Model (POM)?

Without POM, test scripts directly reference locators and UI actions, creating duplication across tests. When a UI element changes, you update every test that touches it. POM centralizes page elements and actions in one class per page. Tests call high-level methods like loginPage.signIn(email, password) instead of repeating find-element-click-type sequences.

A well-designed Page Object exposes methods that represent user actions (fillEmail, submitForm, getErrorMessage), hides locator strategies and implementation details, returns other Page Objects for navigation (clicking "checkout" returns a CheckoutPage), and avoids assertions inside Page Objects, keeping them in the test layer.

POM scales through composition. Complex pages can delegate to Component Objects (e.g., a NavBar component used across multiple Page Objects). For single-page applications with dynamic content, some teams adopt the Screenplay pattern or App Actions pattern, but POM remains the most widely used and interview-relevant pattern.

Two anti-patterns account for most POM failures in the wild. The first is assertions inside page objects: once a page object asserts, it hard-codes one test's expectation into a class shared by many tests, so keep page objects returning state (getErrorMessage(), isLoaded()) and let each test decide what to assert. The second is the god object, a single Page class that accumulates hundreds of methods for every widget on a complex screen; the cure is composition, splitting the page into component objects (NavBar, SearchResults, FilterPanel) that the page object exposes as properties.

The Screenplay pattern is the main alternative worth knowing. Where POM models pages, Screenplay models actors who perform tasks composed of interactions (actor.attemptsTo(Login.withCredentials(...))), which scales better for long multi-persona workflows and reads closer to business language; Serenity BDD popularized it in the Java world. The honest trade-off is that Screenplay brings a steeper learning curve and more indirection, so most teams get further with disciplined POM plus component objects, and interviewers mostly expect you to know Screenplay exists and when its task-first modeling pays off.

Implementation differs meaningfully between Selenium and Playwright. In Selenium, page objects typically hold By locators plus a WebDriver injected through the constructor, often with PageFactory and @FindBy annotations in Java, and every interaction needs explicit waits (WebDriverWait) baked into the methods. In Playwright, the page object receives a Page and stores Locator fields (this.submitButton = page.getByRole('button', { name: 'Sign in' })), which are lazily evaluated and auto-waiting, so the wait plumbing that dominates Selenium page objects largely disappears. Playwright's fixture system also lets you inject fully constructed page objects into tests, replacing the manual new LoginPage(driver) wiring.