Page Object Model (POM) is a widely used design pattern in Selenium automation that helps organize web application automation code by separating page-specific elements and actions from test cases. Following POM best practices makes Selenium frameworks more readable, maintainable, reusable, scalable, and easier to debug.
In a well-designed POM framework, each important application page is represented by a dedicated Java class. The page class contains locators and methods for interacting with that page, while test classes focus mainly on test scenarios, test data, and assertions.
POM becomes especially valuable in large Selenium projects where the same pages, elements, and workflows are used across many test cases.
Course Resource: Selenium Training | Register for Course Demo
Page Object Model is a design pattern in Selenium where web pages or significant sections of an application are represented as separate classes. These classes contain the locators and methods required to interact with the corresponding page.
Instead of placing Selenium locators and WebDriver commands directly inside every test case, the page-specific operations are encapsulated inside page classes.
Test Class
|
v
Page Object
|
+-- Locators
|
+-- Page Actions
|
v
WebDriver
|
v
Web Application
Simply using POM does not automatically create a good automation framework. The page classes must be designed carefully so that they remain easy to maintain as the application grows.
A typical Selenium POM framework separates tests, page classes, utilities, test data, and configuration.
Automation Framework
|
+-- Tests
|
+-- Pages
|
+-- Components
|
+-- Utilities
|
+-- Test Data
|
+-- Configuration
|
+-- Reports
|
+-- Drivers
A common POM best practice is to create a dedicated class for each major application page.
For example, an e-commerce application may contain:
LoginPage.java
HomePage.java
ProductPage.java
CartPage.java
CheckoutPage.java
PaymentPage.java
Each class should primarily represent the behavior and elements of its corresponding page.
Locators should generally be maintained inside the page object instead of being scattered throughout test classes.
Incorrect approach:
@Test
public void loginTest() {
driver.findElement(By.id("username")).sendKeys("admin");
driver.findElement(By.id("password")).sendKeys("admin123");
driver.findElement(By.id("loginButton")).click();
}
Better POM approach:
public class LoginPage {
private WebDriver driver;
private By username = By.id("username");
private By password = By.id("password");
private By loginButton = By.id("loginButton");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void login(String user, String pass) {
driver.findElement(username).sendKeys(user);
driver.findElement(password).sendKeys(pass);
driver.findElement(loginButton).click();
}
}
Locator names should clearly communicate which application element they represent.
Good examples:
private By usernameField = By.id("username");
private By passwordField = By.id("password");
private By loginButton = By.id("loginButton");
private By searchBox = By.id("search");
private By cartIcon = By.id("cart");
Avoid vague names such as:
private By element1;
private By locator2;
private By testObject;
Page-specific locators should generally be private. Tests should interact with the page through meaningful methods rather than directly accessing internal locators.
public class LoginPage {
private By usernameField = By.id("username");
private By passwordField = By.id("password");
private By loginButton = By.id("loginButton");
public void login(String username, String password) {
driver.findElement(usernameField).sendKeys(username);
driver.findElement(passwordField).sendKeys(password);
driver.findElement(loginButton).click();
}
}
This provides encapsulation and prevents test classes from depending directly on page implementation details.
A page object normally receives the WebDriver instance through its constructor.
public class LoginPage {
private WebDriver driver;
public LoginPage(WebDriver driver) {
this.driver = driver;
}
}
This allows the same browser session to be used by the page object and test class.
Page classes should expose meaningful business-level actions rather than requiring tests to perform individual Selenium commands.
For example, instead of writing:
driver.findElement(By.id("username")).sendKeys("admin");
driver.findElement(By.id("password")).sendKeys("admin123");
driver.findElement(By.id("loginButton")).click();
the test should be able to call:
loginPage.login("admin", "admin123");This keeps the test readable and makes the page implementation reusable.
POM methods should represent meaningful user actions whenever practical.
For example:
login()
searchProduct()
addProductToCart()
removeProductFromCart()
proceedToCheckout()
enterShippingDetails()
placeOrder()
These methods make test cases easier to understand because they describe what the user is doing instead of exposing low-level Selenium commands.
Assertions are generally best kept in test classes or dedicated verification/helper layers rather than being scattered throughout page methods.
For example, instead of:
public void login(String username, String password) {
// Login actions
Assert.assertTrue(driver.getTitle().contains("Dashboard"));
}
A cleaner approach is:
loginPage.login(username, password);
Assert.assertTrue(
homePage.isDashboardDisplayed()
);
This keeps the page object focused on page behavior while the test controls the verification.
When an action navigates to another page, the page method can return the corresponding page object.
public HomePage login(String username, String password) {
driver.findElement(usernameField).sendKeys(username);
driver.findElement(passwordField).sendKeys(password);
driver.findElement(loginButton).click();
return new HomePage(driver);
}
The test can then follow the application flow naturally.
HomePage homePage = loginPage.login("admin", "admin123");
homePage.verifyDashboard();
Page classes should normally contain UI interaction logic rather than test-specific data.
Avoid:
public void login() {
usernameField.sendKeys("admin");
passwordField.sendKeys("admin123");
}
Prefer:
public void login(String username, String password) {
usernameField.sendKeys(username);
passwordField.sendKeys(password);
}
The test, Data Provider, configuration, or secure test-data mechanism can supply the actual values.
Test data should be maintained separately from page interaction logic whenever practical.
Test Data
|
+-- Username
+-- Password
+-- Product
+-- Search Keyword
+-- Expected Result
|
v
Test Class
|
v
Page Object
This separation allows the same page methods to be reused with different data sets.
TestNG Data Providers work well with POM because the Data Provider can supply test data while the page object handles UI interactions.
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(String username, String password) {
loginPage.login(username, password);
}
Dynamic web applications often require synchronization. Explicit waits should be implemented in a controlled and reusable manner.
WebDriverWait wait =
new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(
ExpectedConditions.visibilityOfElementLocated(usernameField)
);
Avoid adding arbitrary sleeps throughout page classes.
Thread.sleep() pauses execution for a fixed amount of time regardless of whether the application is ready.
Avoid:
Thread.sleep(5000);Prefer condition-based waits:
wait.until(
ExpectedConditions.elementToBeClickable(loginButton)
);
Explicit waits generally provide better synchronization because the test waits for a meaningful condition.
Large frameworks can centralize commonly used wait operations in utility classes.
public class WaitUtils {
private WebDriver driver;
private WebDriverWait wait;
public WaitUtils(WebDriver driver) {
this.driver = driver;
this.wait = new WebDriverWait(
driver,
Duration.ofSeconds(10)
);
}
public void waitForVisible(By locator) {
wait.until(
ExpectedConditions.visibilityOfElementLocated(locator)
);
}
public void waitForClickable(By locator) {
wait.until(
ExpectedConditions.elementToBeClickable(locator)
);
}
}
Locator stability is important for maintainable Selenium frameworks. Prefer attributes that are stable and meaningful.
Common locator preference can include:
id
name
stable data attributes
accessible attributes
CSS selectors
XPath when appropriate
Avoid fragile locators that depend heavily on changing CSS classes or deeply nested DOM structures.
Long XPath expressions can become fragile when the application's DOM changes.
Avoid unnecessarily complex expressions such as:
/html/body/div[2]/div[1]/div[3]/div[2]/buttonPrefer a stable attribute where available:
By.id("loginButton")or:
By.cssSelector("[data-testid='login-button']")Not every UI element needs to belong directly to a complete page class. Reusable components such as navigation bars, headers, menus, product cards, and dialogs can be represented as component objects.
HomePage
|
+-- HeaderComponent
+-- NavigationComponent
+-- ProductCard
+-- FooterComponent
This approach can reduce duplication when the same component appears on multiple pages.
Suppose an application contains product cards with the same structure. Instead of duplicating product-card locators on every page, create a reusable component.
public class ProductCard {
private WebElement root;
public ProductCard(WebElement root) {
this.root = root;
}
public String getProductName() {
return root.findElement(
By.cssSelector(".product-name")
).getText();
}
public void addToCart() {
root.findElement(
By.cssSelector(".add-to-cart")
).click();
}
}
A page class should not become a large collection of unrelated functionality. Each class should have a clear responsibility.
For example:
LoginPage
-> Login-related actions
SearchPage
-> Search-related actions
CartPage
-> Cart-related actions
CheckoutPage
-> Checkout-related actions
This makes classes easier to understand and maintain.
A common POM problem is creating one enormous class containing every locator and action in the application.
Instead of:
ApplicationPage.java
-> Login
-> Search
-> Products
-> Cart
-> Checkout
-> Payment
-> Profile
-> Reports
prefer smaller, focused page and component classes.
Encapsulation means hiding implementation details and exposing only the operations required by the test.
public class LoginPage {
private By usernameField = By.id("username");
private By passwordField = By.id("password");
private By loginButton = By.id("loginButton");
public void login(String username, String password) {
driver.findElement(usernameField).sendKeys(username);
driver.findElement(passwordField).sendKeys(password);
driver.findElement(loginButton).click();
}
}
The test does not need to know how the username field is located.
Method names should describe the action or behavior clearly.
Good examples:
login()
searchProduct()
selectCategory()
addProductToCart()
removeProduct()
proceedToCheckout()
enterAddress()
placeOrder()
Avoid vague method names such as:
doAction()
click()
execute()
process()
unless the context genuinely makes the meaning clear.
A method should ideally perform one meaningful operation or workflow step.
For example:
public void enterUsername(String username) {
driver.findElement(usernameField).sendKeys(username);
}
public void enterPassword(String password) {
driver.findElement(passwordField).sendKeys(password);
}
public void clickLogin() {
driver.findElement(loginButton).click();
}
For a business-level workflow, these can also be combined:
public void login(String username, String password) {
enterUsername(username);
enterPassword(password);
clickLogin();
}
If the same UI interaction appears in several places, consider creating a reusable method or component.
Instead of repeating:
driver.findElement(By.id("search")).clear();
driver.findElement(By.id("search")).sendKeys(keyword);
driver.findElement(By.id("searchButton")).click();
create:
public void search(String keyword) {
searchBox.clear();
searchBox.sendKeys(keyword);
searchButton.click();
}
Navigation methods should generally perform navigation, while verification methods should communicate whether an expected page or element is present.
public void openLoginPage() {
driver.get(baseUrl + "/login");
}
public boolean isLoginPageDisplayed() {
return driver.findElement(loginButton).isDisplayed();
}
Page methods can return useful information when the test needs to verify a value.
public String getPageTitle() {
return driver.getTitle();
}
public String getUsername() {
return driver.findElement(usernameLabel).getText();
}
The test can then perform assertions:
Assert.assertEquals(
homePage.getPageTitle(),
"Dashboard"
);
Assertions should verify business expectations rather than simply confirming that Selenium commands executed without throwing an exception.
Examples include:
Assert.assertEquals(
checkoutPage.getOrderStatus(),
"Order Confirmed"
);
Assert.assertTrue(
homePage.isDashboardDisplayed()
);
A BasePage can contain genuinely common functionality such as WebDriver access, common waits, navigation helpers, and reusable browser operations.
public class BasePage {
protected WebDriver driver;
protected WebDriverWait wait;
public BasePage(WebDriver driver) {
this.driver = driver;
this.wait = new WebDriverWait(
driver,
Duration.ofSeconds(10)
);
}
protected void click(By locator) {
wait.until(
ExpectedConditions.elementToBeClickable(locator)
).click();
}
}
A BasePage should not become another giant utility class containing application-specific actions.
Good:
BasePage
-> click()
-> type()
-> waitForVisible()
-> getTitle()
Bad:
BasePage
-> login()
-> addProduct()
-> checkout()
-> createUser()
-> generateInvoice()
-> approveOrder()
Application-specific operations should normally remain in their relevant page or component classes.
Selenium projects may use Page Factory-style element initialization, but teams should choose a consistent approach that fits their framework.
public class LoginPage {
private WebDriver driver;
@FindBy(id = "username")
private WebElement usernameField;
@FindBy(id = "password")
private WebElement passwordField;
@FindBy(id = "loginButton")
private WebElement loginButton;
public LoginPage(WebDriver driver) {
this.driver = driver;
PageFactory.initElements(driver, this);
}
}
Whether using By locators or @FindBy, consistency and maintainability are more important than mixing patterns unnecessarily.
A page class should be understandable by another automation engineer without requiring extensive investigation.
A readable class generally contains:
Configuration values such as environment-specific base URLs should generally not be scattered throughout page classes.
Instead, configuration can be centralized:
public class Config {
public static final String QA_URL =
"https://qa.example.com";
public static final String STAGE_URL =
"https://stage.example.com";
}
For larger projects, external configuration is usually preferable to hard-coding environment-specific values in Java source.
Environment values such as QA, staging, and production URLs should be managed independently from page behavior.
Environment
|
+-- QA URL
+-- Stage URL
+-- Production URL
|
v
Config
|
v
WebDriver
|
v
Page Objects
A DriverFactory can centralize browser creation and make the framework easier to extend.
public class DriverFactory {
public static WebDriver createDriver(String browser) {
if (browser.equalsIgnoreCase("chrome")) {
return new ChromeDriver();
}
if (browser.equalsIgnoreCase("firefox")) {
return new FirefoxDriver();
}
if (browser.equalsIgnoreCase("edge")) {
return new EdgeDriver();
}
throw new IllegalArgumentException(
"Unsupported browser: " + browser
);
}
}
A scalable framework can use a DriverFactory to create the browser and then pass the driver to page objects.
WebDriver driver =
DriverFactory.createDriver("chrome");
LoginPage loginPage =
new LoginPage(driver);
loginPage.login("admin", "admin123");
When Selenium tests execute concurrently, sharing one WebDriver instance between multiple threads can cause test interference. A common framework technique is to maintain a driver instance per thread.
public class DriverManager {
private static ThreadLocal<WebDriver> driver =
new ThreadLocal<>();
public static void setDriver(WebDriver webDriver) {
driver.set(webDriver);
}
public static WebDriver getDriver() {
return driver.get();
}
public static void removeDriver() {
driver.remove();
}
}
The exact driver-management design should match the framework's execution model.
TestNG can manage setup, test execution, Data Providers, groups, dependencies, and assertions while POM manages page interaction.
@BeforeMethod
public void setup() {
driver = DriverFactory.createDriver("chrome");
loginPage = new LoginPage(driver);
}
@Test
public void validLoginTest() {
loginPage.login("admin", "admin123");
Assert.assertTrue(homePage.isDashboardDisplayed());
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
@DataProvider(name = "users")
public Object[][] users() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "users")
public void loginTest(String username, String password) {
loginPage.login(username, password);
}
This keeps the test data, test execution, and page interaction responsibilities separated.
Creating WebDriver independently in every test class can lead to duplication.
A centralized DriverFactory or driver-management layer makes browser configuration easier to maintain.
Test
|
v
DriverFactory
|
v
WebDriver
|
v
Page Object
|
v
Application
A test class should describe what is being tested rather than contain every Selenium implementation detail.
Example:
@Test
public void validLoginTest() {
loginPage.login("admin", "admin123");
Assert.assertTrue(
homePage.isDashboardDisplayed()
);
}
This is easier to understand than a test containing dozens of direct Selenium commands.
Large blocks of WebDriver commands inside test methods reduce maintainability.
Instead of:
driver.findElement(By.id("username")).sendKeys("admin");
driver.findElement(By.id("password")).sendKeys("admin123");
driver.findElement(By.id("loginButton")).click();
driver.findElement(By.id("search")).sendKeys("Laptop");
prefer:
loginPage.login("admin", "admin123");
homePage.searchProduct("Laptop");
Page objects should ideally focus on application interaction rather than becoming tightly coupled to TestNG-specific test execution behavior.
This makes the page layer easier to reuse and maintain.
Page methods should describe application actions rather than individual test-case names.
Avoid:
executeTestCaseTC001()
executeLoginTest()
runAdminTest()
Prefer:
login()
logout()
searchProduct()
addToCart()
Tests should interact with page objects through stable methods. If a locator changes, ideally only the page class needs modification.
Test
|
+-- loginPage.login()
|
+-- loginPage.isErrorDisplayed()
|
+-- homePage.searchProduct()
The test does not need to know whether the underlying locator uses an ID, CSS selector, or XPath.
Common technical operations can be extracted into utilities when they are genuinely reusable.
Examples include:
A utility class and a page object serve different purposes.
| Page Object | Utility |
|---|---|
| Represents application UI | Provides reusable technical functionality |
| Contains page locators | Usually does not contain page-specific locators |
| Contains business-level page actions | Contains generic helper operations |
| Example: LoginPage | Example: ExcelReader |
Package organization becomes important as the framework grows.
src/test/java
|
+-- tests
|
+-- pages
|
+-- components
|
+-- utilities
|
+-- drivers
|
+-- data
|
+-- listeners
selenium-automation
|
+-- src
| +-- test
| +-- java
| +-- tests
| | +-- LoginTest.java
| | +-- SearchTest.java
| | +-- CheckoutTest.java
| |
| +-- pages
| | +-- LoginPage.java
| | +-- HomePage.java
| | +-- ProductPage.java
| | +-- CartPage.java
| | +-- CheckoutPage.java
| |
| +-- components
| | +-- HeaderComponent.java
| | +-- ProductCard.java
| |
| +-- utilities
| | +-- WaitUtils.java
| | +-- ConfigReader.java
| | +-- ExcelReader.java
| |
| +-- drivers
| | +-- DriverFactory.java
| |
| +-- data
| +-- LoginDataProvider.java
|
+-- pom.xml
Consistent naming makes automation frameworks easier to understand.
| Item | Example |
|---|---|
| Page Class | LoginPage |
| Test Class | LoginTest |
| Component | HeaderComponent |
| Locator | loginButton |
| Action Method | login() |
| Verification Method | isDashboardDisplayed() |
| Utility | WaitUtils |
Comments should explain non-obvious decisions rather than describe every obvious line of code.
Avoid:
// Click login button
loginButton.click();
Prefer comments that explain why something unusual is required:
// Wait for the asynchronous dashboard request to complete
// before validating the page content.
If the same UI element is required by multiple methods within a page class, define the locator once and reuse it.
private By searchBox = By.id("search");
public void search(String keyword) {
driver.findElement(searchBox).clear();
driver.findElement(searchBox).sendKeys(keyword);
}
public void clearSearch() {
driver.findElement(searchBox).clear();
}
Login is often used by many tests. A reusable login page method can prevent repeated UI code.
public void login(String username, String password) {
driver.findElement(usernameField).sendKeys(username);
driver.findElement(passwordField).sendKeys(password);
driver.findElement(loginButton).click();
}
Tests can then simply call:
loginPage.login(username, password);If an action navigates to another page, clearly represent that transition in the page object design.
public HomePage login(String username, String password) {
enterUsername(username);
enterPassword(password);
clickLogin();
return new HomePage(driver);
}
A page method should return the page object that actually represents the resulting application state. If a login action fails and remains on the login page, blindly returning a HomePage can make tests misleading.
Page transitions should reflect the actual application workflow.
Modern web applications frequently contain dynamic IDs, asynchronous elements, overlays, and changing content.
Good POM design should combine:
Elements can become stale when the DOM is refreshed or replaced. For dynamic pages, storing WebElement references for long periods can increase the chance of stale element problems.
Where appropriate, using a By locator and locating the element when the action is performed can be more resilient.
private By refreshButton = By.id("refresh");
public void clickRefresh() {
driver.findElement(refreshButton).click();
}
A page object should not be designed around only one test case.
For example, a login method should support different credentials:
loginPage.login("admin", "admin123");
loginPage.login("manager", "manager123");
loginPage.login("employee", "employee123");
This allows the same page functionality to support many tests.
When the same action can be performed with different values, accept those values as method parameters.
public void searchProduct(String productName) {
searchBox.clear();
searchBox.sendKeys(productName);
searchButton.click();
}
This is more reusable than creating separate methods for every possible product.
POM should simplify automation rather than make simple actions unnecessarily complicated.
Do not create multiple layers of wrappers when a straightforward page method would be clearer.
Test
|
v
Page Method
|
v
WebDriver
A framework should introduce additional abstraction only when it provides meaningful reuse, consistency, or maintainability.
All page classes should follow a consistent structure.
public class LoginPage {
// WebDriver
private WebDriver driver;
// Locators
private By usernameField = By.id("username");
private By passwordField = By.id("password");
private By loginButton = By.id("loginButton");
// Constructor
public LoginPage(WebDriver driver) {
this.driver = driver;
}
// Actions
public void login(String username, String password) {
driver.findElement(usernameField).sendKeys(username);
driver.findElement(passwordField).sendKeys(password);
driver.findElement(loginButton).click();
}
// Verification
public boolean isLoginButtonDisplayed() {
return driver.findElement(loginButton).isDisplayed();
}
}
As automation frameworks grow, code reviews can help identify poor locator choices, duplicated methods, excessive page responsibilities, synchronization problems, and unsafe parallel-execution patterns.
Useful review questions include:
Page methods should provide meaningful failures so that test reports are useful. Clear method names and appropriate exceptions can make failures easier to understand.
loginPage.login(username, password);
Assert.assertTrue(
homePage.isDashboardDisplayed(),
"Dashboard was not displayed after login"
);
Good test descriptions and meaningful assertions help connect reported failures to business scenarios.
For failed Selenium tests, frameworks often capture screenshots. Screenshot handling can be implemented in listeners or utilities instead of duplicating screenshot code throughout page classes.
Test Failure
|
v
TestNG Listener
|
v
Screenshot Utility
|
v
Screenshot File
|
v
Test Report
Logging can help diagnose failures without placing excessive print statements throughout the framework.
Useful logging may include:
Starting login
Entering username
Clicking login button
Navigating to dashboard
Validating dashboard
Sensitive values such as passwords and tokens should not be logged.
A clean POM framework integrates well with CI/CD systems because page logic, test logic, configuration, test data, and driver management are separated.
Developer Commit
|
v
CI/CD Pipeline
|
v
Maven Build
|
v
TestNG
|
v
Selenium
|
v
POM
|
v
Application
|
v
Reports
Maven can manage Selenium, TestNG, reporting, Apache POI, logging, and other project dependencies.
mvn clean testA well-organized POM framework can therefore be integrated into repeatable local and CI test execution.
| Practice | Recommendation |
|---|---|
| Page Classes | Create focused classes for pages or meaningful UI components. |
| Locators | Keep locators centralized and use stable selectors. |
| Encapsulation | Keep implementation details private. |
| Methods | Expose meaningful business-level actions. |
| Test Data | Keep data separate from page logic. |
| Assertions | Keep important test verification in test or verification layers. |
| Waits | Prefer condition-based waits over arbitrary sleeps. |
| Driver | Centralize browser creation and manage parallel execution safely. |
| Components | Extract repeated UI sections into reusable components. |
| Configuration | Keep environment configuration outside page classes. |
| Security | Do not expose passwords, tokens, or secrets in logs or source control. |
| Maintenance | Keep classes small, readable, and focused. |
@Test
public void loginTest() {
driver.findElement(By.id("username"))
.sendKeys("admin");
driver.findElement(By.id("password"))
.sendKeys("admin123");
driver.findElement(By.id("loginButton"))
.click();
Assert.assertTrue(
driver.getTitle().contains("Dashboard")
);
}
@Test
public void loginTest() {
loginPage.login("admin", "admin123");
Assert.assertTrue(
homePage.isDashboardDisplayed()
);
}
The second approach separates page interaction from the test scenario and is generally easier to maintain as the application changes.
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class LoginPage {
private WebDriver driver;
private By usernameField =
By.id("username");
private By passwordField =
By.id("password");
private By loginButton =
By.id("loginButton");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void login(String username, String password) {
driver.findElement(usernameField)
.sendKeys(username);
driver.findElement(passwordField)
.sendKeys(password);
driver.findElement(loginButton)
.click();
}
}
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class HomePage {
private WebDriver driver;
private By dashboard =
By.id("dashboard");
public HomePage(WebDriver driver) {
this.driver = driver;
}
public boolean isDashboardDisplayed() {
return driver.findElement(dashboard)
.isDisplayed();
}
}
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;
public class LoginTest {
private WebDriver driver;
private LoginPage loginPage;
private HomePage homePage;
@BeforeMethod
public void setup() {
driver = new ChromeDriver();
driver.manage().window().maximize();
driver.get("https://example.com/login");
loginPage = new LoginPage(driver);
homePage = new HomePage(driver);
}
@Test
public void validLoginTest() {
loginPage.login(
"admin",
"admin123"
);
Assert.assertTrue(
homePage.isDashboardDisplayed(),
"Dashboard was not displayed"
);
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
Test Classes
|
v
+----------------+
| Page Objects |
+----------------+
| | |
v v v
Login Home Checkout
|
v
Page Components
|
v
Selenium WebDriver
|
v
Web Application
Supporting Layers:
-------------------
Driver Factory
Config Reader
Wait Utilities
Test Data
Data Providers
Screenshot Utility
Reporting
Logging
CI/CD
A strong POM framework generally follows several important design principles.
POM is a design pattern that represents application pages as classes containing their locators and interactions.
POM helps separate UI interaction logic from test logic and improves maintainability and reusability.
In a POM design, page-specific locators are generally maintained inside the relevant page classes.
Private locators provide encapsulation and prevent tests from depending directly on page implementation details.
A page class generally contains page-specific locators, a WebDriver reference, constructor, and meaningful page interaction methods.
Test data should generally be separated from page interaction logic so that page methods remain reusable.
Important test assertions are generally better maintained in test or verification layers, although page objects can expose methods that return values or state for assertions.
A BasePage is a common parent class that can provide genuinely shared browser operations such as waits and common interactions.
A DriverFactory centralizes WebDriver creation and can simplify browser selection and driver configuration.
A component object represents a reusable UI section such as a header, menu, product card, or dialog.
It uses a fixed delay rather than waiting for an application condition and can make tests slower or less reliable.
POM can support parallel execution when the underlying framework manages independent WebDriver instances and test data safely for each thread.
Yes. DataProvider can supply test data while POM handles the corresponding UI interactions.
When a page locator changes, the relevant page class can often be updated without modifying every test that uses that page.
Common mistakes include creating giant page classes, duplicating locators, mixing test data with UI logic, and creating excessive abstraction.
| Concept | Best Practice |
|---|---|
| Page Object | Represent a page or meaningful UI component. |
| Locators | Keep them centralized and stable. |
| Methods | Use meaningful business-level actions. |
| WebDriver | Pass it through constructors or a controlled driver-management layer. |
| Test Data | Keep it separate from page implementation. |
| Assertions | Perform meaningful verification in the test/verification layer. |
| Waits | Use condition-based synchronization. |
| Components | Extract repeated UI sections. |
| DriverFactory | Centralize browser creation. |
| Utilities | Keep generic technical helpers separate from page classes. |
| Parallel Execution | Use isolated, thread-safe browser sessions. |
| Security | Protect passwords, tokens, and other secrets. |
Page Object Model is an important design pattern for building maintainable Selenium automation frameworks. The main idea is to represent application pages and reusable UI components as classes and keep their locators and interaction methods organized inside those classes.
Following POM best practices means using stable locators, meaningful methods, encapsulation, reusable components, proper synchronization, separated test data, centralized driver management, and clear project organization.
A well-designed POM framework should keep test cases focused on business scenarios while page classes handle Selenium interactions. TestNG Data Providers can be used for multiple data sets, DriverFactory can manage browsers, utilities can handle common framework operations, and reporting/listeners can handle execution results.
The ultimate goal is not simply to create page classes, but to create an automation framework that remains readable, reusable, reliable, and maintainable as the application and test suite grow.
Learn more about Selenium automation and professional testing practices:
Final Takeaway: Good POM practices keep Selenium automation organized by separating page interaction, test scenarios, test data, configuration, driver management, and reusable framework utilities. A clean POM structure reduces duplication and makes UI changes easier to manage across a growing automation suite.
