Framework Design

Page Object Model (POM)

Learning Outcome

Recall

Page Object Model (POM)

To understand POM, you need to revise the topics like

Object-Oriented Programming (OOP)

Programming Language Basics

Selenium WebDriver Fundamentals

HTML & DOM Structure

Classes, objects, methods, encapsulation, and inheritance

Java / Python / any language used for automation

Locators (id, xpath, css), actions (click, sendKeys), waits

Understanding web elements and how they are structured

Test Automation Basics

Basic Framework Knowledge

Test cases, assertions, test execution flow

Familiarity with tools like TestNG / PyTest (optional but helpful)

These topics will make learning POM much easier and more effective.

Think of Page Object Model (POM) like ordering food in a restaurant:

Menu (Page Class):
The menu lists all available dishes (elements and actions on a webpage).

Waiter (Methods in Page Class):
You don’t go into the kitchen yourself—you tell the waiter what you want. Similarly, tests don’t directly interact with UI elements; they call methods

Analogy to Understand Need of POM

Kitchen (UI / Web Page):
he actual work (clicking buttons, entering text) happens behind the scenes.

Customer (Test Script):
You simply place an order (call methods) without worrying about how the food is prepared.

How this relates to POM:

You separate responsibilities (customer ≠ kitchen)

You reuse the same menu/waiter for multiple orders (reusability)

If something changes (recipe/UI), only the kitchen/menu needs updating—not the customer’s behavior

This way, POM keeps your test code clean, organized, and easy to maintain, just like a well-managed restaurant system

Why use Page Object Model (POM)?.

POM is used to make test automation:

● Easier to maintain
● More readable
● Reusable
● Scalable
● Less prone to errors

Without POM, automation scripts become:

● Repetitive
● Hard to maintain
● Difficult to update when UI changes

What is Page Object Model (POM)?

Page Object Model (POM) is a design pattern used in test automation where each web page of an application is represented as a separate class.

Each page class contains:

Web elements (locators)

Methods (actions on those elements)

The main idea is to separate test logic from UI interaction logic.

Structure of  POM

Page Classes (Page Objects)

Each page of application is a class:

• LoginPage

• HomePage

• DashboardPage

They contain:

• Locators (elements)

• Methods (actions)

Example:

• enterUsername()

• clickLogin()

• getTitle()

Test Classes

Test classes contain:

• Test cases

• Assertions

• Test flow (no direct UI handling)

They call methods from page classes.

Object Repository (Inside Page Classes)

Stores UI elements like:

• ID

• XPath

• CSS selectors

AutomationFramework/

│

├── src/main/java

│   ├── pages/

│   │   ├── LoginPage.java

│   │   ├── HomePage.java

│   │   └── DashboardPage.java

│   │

│   ├── utilities/

│   │   ├── WebDriverUtility.java

│   │   ├── ConfigReader.java

│   │   └── ScreenshotUtility.java

│

├── src/test/java

│   ├── tests/

│   │   ├── LoginTest.java

│   │   └── HomeTest.java

│

├── src/main/resources

│   ├── config.properties

│   ├── testdata.json

│

├── drivers/

├── reports/

├── testng.xml

└── pom.xml

Working of POM (Flow)

1. Test script calls page class method

2. Page class interacts with web elements

3. Selenium performs actions on browser

4. Result is validated in test class

Example of POM

XML Report

test-output/testng-results.xml

Purpose :

• Machine-readable format

• Used by CI/CD tools like Jenkins

Contains:

• Suite structure

• Test methods

• Execution status

• Time stamps

• Exceptions

D. JUnit Report

Purpose :

Converts TestNG results into JUnit format

Useful for tools that support only JUnit (like older CI systems)

test-output/junitreports

Summary

Where does TestNG generate default reports after execution?

Where does TestNG generate default reports after execution?