Page object model
Without a pattern like this, selectors end up scattered across every test file that needs them. A login button's selector might get copy-pasted into thirty different tests, and when a developer renames that button's ID, all thirty break at once, each needing the same one-line fix repeated by hand. The page object model exists to stop that from happening.
The idea is straightforward: give each page, or a meaningful piece of a page, its own class. That class holds the selectors for the elements on it, plus methods for the actions a test would actually take, a LoginPage class might expose a login(username, password) method that finds both fields, types into them, and clicks submit, all in one call. A test then reads as a sequence of actions, log in, add an item, go to checkout, instead of a list of raw element lookups and clicks.
It's most closely associated with Selenium and WebDriver-based suites, where organizing tests this way is close to a default convention. The same idea works fine with Playwright or Cypress too, though some newer frameworks offer their own built-in patterns, like fixtures, that cover part of the same reuse problem in a different way.
How it's structured
- One class per page, or per major reusable component, like a navigation bar.
- Locators defined once, as class properties or private methods, not scattered through test files.
- Action methods, like
login()oraddToCart(), that combine several low-level steps into a single call. - Tests import page objects and call their methods, rather than finding elements and acting on them directly.
- A shared base page class often holds common behavior, like waiting for a page to finish loading.
Where it shows up
- A login flow reused across dozens of test cases, defined once in a single page class.
- A checkout page whose layout changes often, so a fix lives in one file instead of forty.
- Onboarding a new tester who can write a readable test without knowing the underlying selector strategy.
- A large regression suite, where the pattern keeps a growing number of tests from drifting apart.
Benefits and challenges
| Benefit | Challenge |
|---|---|
| A UI change means updating one page class, not every test that touches that page. | Pays off less on a small suite, the extra layer of classes is real overhead for only a handful of tests. |
| Tests read like a sequence of actions a user would take, easier for a non-engineer to follow. | A page object built too generically becomes its own maintenance burden, especially once it tries to cover every possible page state. |
| Encourages reusing a login or navigation flow instead of copy-pasting the same steps into every test. | Still needs someone to keep locators current, it organizes the maintenance work, it doesn't remove it. |
Frequently asked questions
Do I need a separate class for every single page?
Not necessarily. It's common to give a large or complex page its own class, and combine several small, related screens or a repeated UI component, like a header, into one shared class instead of one file per screen. The goal is organizing around what's genuinely reused, not enforcing a rigid one-to-one rule.
Is the page object model still relevant with modern frameworks like Playwright?
Yes, though some teams lean on it more loosely than they did with classic Selenium suites. Playwright and Cypress both work fine with the pattern, and many teams still use it, even as newer built-in features cover some of the same reuse the pattern was originally built to solve.
What's the difference between a page object and a locator repository?
A locator repository is just a central place that stores selectors. A page object goes further, bundling those locators together with the actions a test can take on that page, like clicking a button or reading a field's text, so a test calls one method instead of finding an element and acting on it as two separate steps.
How Klarent helps
Klarent's AI agents recognize an element by what it does on the page rather than a fixed selector, and self-healing execution repairs a test automatically when a page's structure shifts, taking on the maintenance work a page object model was originally built to organize by hand.
Ready to eliminate QA bottlenecks? Talk to our team for a personalised walkthrough.
More terms