Page Object Model concept in Testing Fundamentals - Deep Dive

Overview - Page Object Model concept

What is it?

Page Object Model (POM) is a design pattern used in software testing to organize and simplify how tests interact with web pages. It creates a separate class for each page or component, encapsulating the page elements and actions in one place. This makes tests easier to read, maintain, and update. Instead of repeating code, testers use these page classes to perform actions and verify results.

Why it matters

Without POM, test scripts become long, messy, and hard to maintain because they mix test logic with page details. When the web page changes, many tests break and need fixing. POM solves this by isolating page details, so changes affect only one place. This saves time, reduces errors, and makes testing more reliable and scalable.

Where it fits

Before learning POM, you should understand basic automated testing concepts and how to locate elements on a web page. After POM, you can learn advanced test design patterns, test frameworks integration, and continuous testing practices.

Mental Model

Core Idea

Page Object Model organizes web page details into separate classes so tests can use simple, clear actions without worrying about page internals.

Think of it like...

Imagine a TV remote control: you don’t need to know how the TV works inside; you just press buttons like volume or channel. POM is like creating a remote for each web page, so tests just press buttons without handling the complex inner details.

┌─────────────────────────┐
│       Test Script       │
│  ┌───────────────────┐  │
│  │ Page Object Class │  │
│  │  - locators       │  │
│  │  - actions        │  │
│  └───────────────────┘  │
└─────────────┬───────────┘
              │ uses
              ▼
    ┌───────────────────┐
    │   Web Page UI     │
    │  - buttons        │
    │  - text fields    │
    └───────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Automated Web Testing

Concept: Learn what automated web testing is and why we need it.

Automated web testing uses software tools to simulate user actions on websites, like clicking buttons or entering text. This helps check if the website works correctly without doing it manually every time. Tests run faster and can be repeated often.

Result

You know why we automate tests and the basic idea of simulating user actions.

Understanding the purpose of automation sets the stage for organizing tests better with patterns like POM.

2

Foundation

Locating Web Page Elements

Concept: Learn how to find buttons, fields, and other parts on a web page for testing.

Web pages have elements identified by locators like ID, name, or CSS selectors. Test scripts use these locators to find and interact with elements. For example, a login button might have an ID 'loginBtn' that tests use to click it.

Result

You can identify and use locators to interact with web page elements.

Knowing how to locate elements is essential before organizing them into page objects.

3

Intermediate

Creating Page Object Classes

🤔Before reading on: do you think storing locators and actions together helps or complicates test scripts? Commit to your answer.

Concept: Introduce the idea of grouping locators and actions for a page into one class.

Instead of writing locators and actions directly in tests, create a class for each page. This class holds locators as variables and methods for actions like clicking or typing. Tests then call these methods, keeping test code clean.

Result

Tests become shorter and easier to read because page details are hidden inside page classes.

Grouping page details reduces duplication and makes tests more maintainable.

4

Intermediate

Using Page Objects in Tests

🤔Before reading on: do you think tests should know how to find elements or just call page methods? Commit to your answer.

Concept: Learn how tests interact with page objects by calling their methods instead of handling locators directly.

Tests create instances of page classes and call methods like loginPage.enterUsername('user'). This hides locator details from tests, so if the page changes, only the page class needs updating.

Result

Tests focus on what to do, not how to do it, improving clarity and reducing errors.

Separating test logic from page details makes tests more stable and easier to update.

5

Advanced

Handling Page Changes Efficiently

🤔Before reading on: do you think changing a locator in one place updates all tests automatically? Commit to your answer.

Concept: Understand how POM helps manage changes in web pages by centralizing locators.

When a page element changes, update its locator only in the page object class. All tests using that class automatically use the new locator. This avoids fixing many tests individually.

Result

Maintenance becomes faster and less error-prone when web pages evolve.

Centralizing locators prevents widespread test failures and saves time.

6

Expert

Advanced POM Patterns and Pitfalls

🤔Before reading on: do you think all page actions should be in one class or split by components? Commit to your answer.

Concept: Explore splitting page objects into smaller components and avoiding common design mistakes.

Large pages can be split into component objects (e.g., header, footer) for reuse. Avoid putting assertions inside page objects; keep them in tests. Also, beware of overloading page objects with too many responsibilities, which makes maintenance hard.

Result

You learn to design scalable, clean page objects that work well in large projects.

Knowing advanced structuring prevents messy code and supports team collaboration.

Under the Hood

POM works by creating classes that store element locators and methods to interact with those elements. When a test calls a method, it triggers commands to the browser driver, which finds the element using the locator and performs actions like click or type. This abstraction hides the complexity of browser commands from tests.

Why designed this way?

POM was designed to separate test logic from page details to reduce duplication and improve maintainability. Earlier approaches mixed locators and test steps, causing fragile tests. POM’s modular design allows easy updates and clearer tests, which was a big improvement over monolithic scripts.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Test Script   │──────▶│ Page Object   │──────▶│ Browser Driver│
│ - calls page  │       │ - locators    │       │ - finds and   │
│   methods     │       │ - actions     │       │   interacts   │
└───────────────┘       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think putting assertions inside page objects is a good practice? Commit to yes or no before reading on.

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

Reality: Page objects should only handle page interactions; assertions belong in test scripts to keep responsibilities separate.

Why it matters: Mixing assertions into page objects makes them less reusable and harder to maintain, causing confusion when tests fail.

Quick: Do you think one page object class should handle the entire website? Commit to yes or no before reading on.

Common Belief: Some think a single page object can manage all pages for simplicity.

Reality: Each page or component should have its own page object to keep code organized and manageable.

Why it matters: Using one big class leads to bloated code that is difficult to update and understand.

Quick: Do you think POM eliminates all test maintenance? Commit to yes or no before reading on.

Common Belief: People often believe POM removes the need to update tests when pages change.

Reality: POM reduces maintenance but does not eliminate it; page objects still need updates when UI changes.

Why it matters: Expecting zero maintenance leads to neglect and broken tests when pages evolve.

Quick: Do you think storing locators as global variables outside page objects is better? Commit to yes or no before reading on.

Common Belief: Some think keeping locators separate from page objects improves reuse.

Reality: Locators belong inside page objects to encapsulate page details and avoid scattering them across tests.

Why it matters: Separating locators breaks encapsulation, causing duplication and harder maintenance.

Expert Zone

1

Page objects can be designed to lazy-load elements, improving test speed by finding elements only when needed.

2

Using inheritance or composition in page objects allows sharing common behaviors but requires careful design to avoid tight coupling.

3

Advanced POM implementations integrate with test frameworks to support dynamic waits and retries, handling flaky elements gracefully.

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 are better suited.

Production Patterns

In real projects, teams use layered page objects with base classes for common actions, component objects for reusable parts, and factory patterns to manage page object creation dynamically.

Connections

Model-View-Controller (MVC)

Both separate concerns by organizing code into distinct parts.

Understanding MVC helps grasp why POM separates page structure from test logic, improving maintainability.

Software Design Patterns

POM is a specific design pattern applying principles like encapsulation and abstraction.

Knowing general design patterns clarifies why POM improves code quality and test reliability.

Human Factors in User Interface Design

POM abstracts UI details, similar to how good UI design hides complexity from users.

Recognizing this connection shows how POM improves tester experience by simplifying interactions.

Common Pitfalls

#1 Mixing test assertions inside page object methods.

Wrong approach:

class LoginPage {
void verifyLoginSuccess() {
assert element.isDisplayed();
}
}

Correct approach:

class LoginPage {
boolean isLoginSuccessVisible() {
return element.isDisplayed();
}
}
// Assertion done in test script

Root cause:

Confusing responsibilities between page interaction and test verification.

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

Wrong approach:

test.click('#submitBtn');

Correct approach:

loginPage.clickSubmitButton();

Root cause:

Not using POM abstraction leads to duplicated locators and fragile tests.

#3 Creating one huge page object class for multiple pages.

Wrong approach:

class AllPages {
// locators and methods for login, dashboard, profile all mixed
}

Correct approach:

class LoginPage {}
class DashboardPage {}
class ProfilePage {}

Root cause:

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

Key Takeaways

Page Object Model organizes web page details into classes to simplify and stabilize automated tests.

Separating locators and actions from test logic reduces duplication and eases maintenance when pages change.

Tests become clearer and more reliable by calling page object methods instead of handling raw locators.

Avoid mixing assertions or multiple pages in one page object to keep code clean and reusable.

Advanced POM designs use components and integration with test frameworks for scalable, robust testing.