Page Object Model: Design Pattern for UI Automation

The Page Object Model (POM) is a design pattern for UI automation: each page (or major component) is represented by a class that holds locators and actions. Tests use these classes instead of raw WebDriver calls. This post explains why and how to use it.

What is the Page Object Model?

• Page class: One class per page (or modal, section). It contains:
  • Locators: How to find elements (e.g. login button, email field).
  • Actions: Methods that perform steps (e.g. login(email, password) that types and clicks).
• Test: Calls page methods (e.g. loginPage.login("a@b.com", "pass")) and asserts. No locators or WebDriver calls in the test itself.

When the UI changes, you update the page class in one place; tests stay the same.

Benefits

• Maintainability: One place to update when selectors or flow change.
• Readability: Tests read like user actions ("login", "add to cart") instead of low-level clicks.
• Reuse: Same page class used by many tests; no duplicated locators or steps.
• Less duplication: Locators and flows defined once.

Simple structure

• pages/LoginPage.java (or .py): locators + login(email, password).
• pages/HomePage.java: locators + goToCart(), getCartCount().
• Test: loginPage.login(...); homePage.goToCart(); assert ...

Keep page methods small and focused; return new page objects when navigation happens (e.g. login() returns HomePage).

Summary

• Page Object = one class per page (or component) with locators and action methods; tests use these methods only.
• Improves maintainability, readability, and reuse; centralizes UI changes.
• Structure: pages package + one class per page; tests call page methods and assert.