Why POM creates maintainable test code in Selenium Java - Why It Works This Way

Overview - Why POM creates maintainable test code

What is it?

Page Object Model (POM) is a design pattern in test automation that organizes web page elements and actions into separate classes. Each page of the application has a corresponding class that contains locators and methods to interact with that page. This separation helps testers write cleaner and more readable test scripts. It makes tests easier to maintain when the web pages change.

Why it matters

Without POM, test code mixes page details and test logic, making it hard to update when the website changes. This leads to fragile tests that break often and require lots of time to fix. POM solves this by isolating page structure from test steps, so changes in the UI only need updates in one place. This saves time, reduces errors, and keeps tests reliable.

Where it fits

Before learning POM, you should understand basic Selenium commands and how to locate web elements. After mastering POM, you can learn advanced test design patterns like the Screenplay pattern or integrate POM with test frameworks for better reporting and parallel execution.

Mental Model

Core Idea

POM creates maintainable test code by separating page details from test logic, so changes in the UI affect only one place in the code.

Think of it like...

Think of POM like a remote control for a TV: instead of pressing buttons directly on the TV (page), you use the remote (page object) that knows how to operate the TV. If the TV changes, you only need to update the remote, not relearn how to watch shows.

┌───────────────────────┐      ┌───────────────────────┐
│      Test Script      │─────▶│    Page Object Class   │
│ (Test logic & asserts)│      │ (Locators & actions)  │
└───────────────────────┘      └───────────────────────┘
               ▲                             │
               │                             ▼
        ┌───────────────────────────────────────────┐
        │               Web Page UI                  │
        └───────────────────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Test Code Structure

Concept: Test code mixes locating elements and test steps without separation.

In simple Selenium tests, you write code that finds buttons, inputs text, and checks results all in one place. For example, locating a login button and clicking it happens inside the test method itself.

Result

Tests work but are hard to read and fix when the page changes.

Knowing that mixing page details and test logic makes tests fragile helps see why separation is needed.

2

Foundation

What is Page Object Model (POM)?

Concept: POM organizes page elements and actions into separate classes.

Each web page gets a class with locators and methods like clickLoginButton(). Tests call these methods instead of directly finding elements.

Result

Tests become cleaner and easier to read.

Separating page details into objects creates a clear boundary between UI and test logic.

3

Intermediate

How POM Improves Maintainability

🤔Before reading on: do you think changing a button's locator requires updating all tests or just one place? Commit to your answer.

Concept: POM centralizes UI changes in page classes, reducing test breakage.

If a button's locator changes, you update it only in the page object class. All tests using that method automatically use the new locator.

Result

Less duplicated code and fewer test failures after UI changes.

Understanding that one change in a page class fixes many tests explains why POM saves maintenance effort.

4

Intermediate

Encapsulating Page Behavior

Concept: POM hides complex UI interactions inside methods.

Instead of tests handling clicks and waits, page objects provide simple methods like login(username, password). This hides details like waiting for elements or filling multiple fields.

Result

Tests become shorter and focus on what to test, not how.

Knowing that encapsulation reduces test code complexity helps keep tests focused and stable.

5

Intermediate

Using POM with Test Frameworks

Concept: POM works well with frameworks like JUnit or TestNG for better structure.

Tests use page objects inside setup and test methods. Frameworks handle test execution and reporting, while POM handles UI interaction.

Result

Tests are organized, reusable, and easy to run automatically.

Combining POM with frameworks creates a professional test suite that scales.

6

Advanced

Avoiding Common POM Pitfalls

🤔Before reading on: do you think putting assertions inside page objects is good practice? Commit to your answer.

Concept: Page objects should not contain test assertions to keep separation clear.

Assertions belong in test scripts, not page classes. Mixing them makes page objects less reusable and harder to maintain.

Result

Clear roles for page objects and tests improve code quality.

Understanding role separation prevents tangled code and improves maintainability.

7

Expert

Scaling POM for Large Projects

🤔Before reading on: do you think one page object per page is always enough in complex apps? Commit to your answer.

Concept: Large apps may need multiple page objects per page or component objects for better modularity.

Breaking pages into smaller components with their own objects helps manage complexity. This also supports parallel test development and easier updates.

Result

Highly maintainable and scalable test code that adapts to complex UIs.

Knowing when and how to modularize page objects is key for professional test automation.

Under the Hood

POM works by creating classes that store locators as variables and expose methods that perform actions on those elements. When tests call these methods, the page object uses Selenium WebDriver commands to interact with the browser. This abstraction means tests never directly access locators, so changes in locators only require updating the page object class. The test code calls stable methods, keeping tests unaffected by UI changes.

Why designed this way?

POM was designed to solve the problem of brittle tests caused by UI changes. Early test scripts mixed UI details and test logic, causing high maintenance costs. By separating page structure into objects, POM reduces duplication and isolates changes. Alternatives like hardcoding locators in tests were rejected because they made tests fragile and hard to read.

┌─────────────────────────────┐
│        Test Script          │
│  Calls methods like login() │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│      Page Object Class       │
│  Stores locators and methods │
│  Uses WebDriver internally   │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│       Web Browser UI         │
│  Receives commands to click,│
│  type, and read elements    │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does POM mean putting test assertions inside page object methods? Commit yes or no.

Common Belief: Many think page objects should include assertions to verify page state.

Reality: Assertions belong in test scripts, not page objects, to keep roles separate.

Why it matters: Mixing assertions in page objects makes them less reusable and harder to maintain.

Quick: Is one page object class always enough for a complex web page? Commit yes or no.

Common Belief: One page object per page is sufficient regardless of page complexity.

Reality: Complex pages often need multiple page objects or component objects for maintainability.

Why it matters: Using a single large page object leads to bloated code and harder updates.

Quick: Does POM eliminate the need to update tests when UI changes? Commit yes or no.

Common Belief: POM means tests never break when UI changes.

Reality: POM reduces updates to one place but page objects still need maintenance when UI changes.

Why it matters: Ignoring page object updates causes tests to fail despite using POM.

Quick: Can POM be used only with Selenium? Commit yes or no.

Common Belief: POM is only for Selenium WebDriver tests.

Reality: POM is a design pattern usable with many UI automation tools.

Why it matters: Limiting POM to Selenium restricts its broader applicability and learning.

Expert Zone

1

Page objects should avoid exposing raw WebDriver calls to keep abstraction clean.

2

Using lazy loading for elements in page objects improves performance and reduces stale element errors.

3

Combining POM with dependency injection frameworks enhances test modularity and parallel execution.

When NOT to use

POM is less effective for very simple or one-off tests where overhead is unnecessary. For API testing or non-UI tests, other patterns like service objects or test data builders are better suited.

Production Patterns

In real projects, teams create base page classes for shared behavior, use component objects for reusable UI parts, and integrate POM with CI pipelines for automated regression testing.

Connections

Single Responsibility Principle (SRP)

POM applies SRP by separating page structure from test logic.

Understanding SRP helps grasp why POM improves maintainability by giving each class one clear job.

Model-View-Controller (MVC) Pattern

POM resembles MVC by separating UI representation (page objects) from control logic (tests).

Knowing MVC clarifies how POM organizes code to reduce dependencies and improve clarity.

Modular Design in Manufacturing

POM’s modular page objects are like interchangeable parts in manufacturing.

Seeing POM as modular design shows how isolating parts reduces repair time and cost in software tests.

Common Pitfalls

#1 Mixing test assertions inside page object methods.

Wrong approach:

public void verifyLoginSuccess() {
Assert.assertTrue(driver.findElement(successMessage).isDisplayed());
}

Correct approach:

public boolean isLoginSuccessMessageDisplayed() {
return driver.findElement(successMessage).isDisplayed();
}

// Assertion in test script:
Assert.assertTrue(loginPage.isLoginSuccessMessageDisplayed());

Root cause:

Confusing the roles of page objects and test scripts leads to tangled code and poor reuse.

#2 Hardcoding locators in multiple test scripts instead of page objects.

Wrong approach:

driver.findElement(By.id("submitBtn")).click(); // repeated in many tests

Correct approach:

public void clickSubmit() {
driver.findElement(submitButton).click();
}
// Tests call clickSubmit() method

Root cause:

Not centralizing locators causes duplicated code and high maintenance.

#3 Creating one huge page object for a complex page.

Wrong approach:

public class DashboardPage {
// 100+ locators and methods for all widgets
}

Correct approach:

public class DashboardPage {
private WidgetA widgetA;
private WidgetB widgetB;
// Each widget has its own class
}

Root cause:

Ignoring modular design principles leads to bloated, hard-to-maintain code.

Key Takeaways

Page Object Model separates page details from test logic, making tests easier to read and maintain.

Centralizing locators and actions in page objects means UI changes require updates in only one place.

Keeping assertions out of page objects preserves clear roles and improves code reuse.

Modularizing page objects for complex pages prevents bloated classes and supports scalable tests.

Understanding POM’s design principles helps build robust, maintainable test automation frameworks.