What is Page Object Model (POM) in Playwright? A Complete Beginner-to-Advanced Guide with Cucumber and TestNG
If you are working in test automation, especially with modern tools like Playwright, you have probably heard about the Page Object Model (POM) design pattern. Whether you are an automation tester, SDET, or someone preparing for interviews, understanding POM is extremely important.
In this detailed, SEO-optimized, AdSense-friendly guide, you will learn:
What is Page Object Model (POM)?
Why POM is important in Playwright automation
Benefits of using POM
Real-time example using Playwright + Cucumber + TestNG
Complete framework structure explanation
Automation of OrangeHRM login page using POM
Let’s start step by step.
What is Page Object Model (POM)?
Page Object Model (POM) is a design pattern used in test automation where each web page (or component) of an application is represented as a separate class.
In simple words:
👉 Every page = One Java class
👉 All locators = Inside that class
👉 All actions (methods) = Inside that class
Instead of writing element locators and actions directly inside test scripts, we define them in separate Page Classes.
Each Page Class contains:
Locators – Web elements on that page (like username field, password field, login button)
Methods – Actions that can be performed on those elements (like enterUsername(), clickLogin())
This creates a clean separation between:
Test Logic
Page Structure
Page Object Model in Playwright
When using Playwright with Java, the Page Object Model works beautifully because Playwright provides powerful APIs for interacting with web elements.
In POM with Playwright:
Each webpage is represented as a class.
Inside that class:
Define locators for elements.
Define methods to interact with those elements.
In test scripts:
Call the methods from the Page Object class.
Instead of this (bad practice):
We do this (clean practice):
This makes the automation framework scalable and maintainable.
Why Use Page Object Model in Playwright?
Playwright supports:
Parallel execution
Cross-browser testing
Complex UI interactions
Modern web applications
In large automation projects, tests can become messy if everything is written inside test classes.
Using POM helps:
1. Structured Framework
Your automation code becomes organized and readable.
2. Easy Maintenance
If a locator changes, you update it in one place (Page class) instead of updating 50 test cases.
3. Better Collaboration
Teams can work on different page classes independently.
4. Clean Architecture
UI layer and test logic layer remain separate.
Benefits of Page Object Model
Let’s understand the advantages clearly.
1. Reusability
Common actions like login can be reused across multiple test cases.
Example:
Login test
Logout test
Add Employee test
Delete Employee test
All can reuse loginPage.login() method.
2. Maintainability
If the login button locator changes:
Old:
New:
You only change it in LoginPage.java, not in every test file.
3. Readability
Test scripts become business-readable:
Instead of technical locator-heavy code.
4. Separation of Concerns
Page classes → Handle UI elements
Test classes → Handle validations and scenarios
This follows good automation design principles.
Website to be Automated
For this example, we are automating the OrangeHRM demo application:
https://opensource-demo.orangehrmlive.com/web/index.php/auth/login
This is a popular demo website used for automation practice.
Automation Framework Structure (Playwright + Cucumber + TestNG)
In this example, we are using:
Playwright (for browser automation)
Cucumber (for BDD)
TestNG (for execution)
Maven (for dependency management)
1. Maven Dependencies
Below are the required dependencies for Playwright, Cucumber, and TestNG:
These dependencies allow integration between Playwright, Cucumber, and TestNG.
2. Feature File (login.feature)
Feature files are written using Gherkin syntax.
This makes tests readable for non-technical stakeholders.
3. PlaywrightFactory.java (Browser Setup Utility)
This class is responsible for:
Initializing Playwright
Launching browser
Creating context
Providing Page object
Closing browser
It follows centralized browser management.
Key responsibilities:
Avoid duplicate browser initialization code
Improve framework scalability
Maintain single browser lifecycle control
4. LoginPage.java (Page Object Class)
This is the core of the Page Object Model.
Inside this class:
Locators:
Username field
Password field
Login button
Dashboard header text
Methods:
navigateToLoginPage()
enterUsername()
enterPassword()
clickLogin()
isDashboardVisible()
This class represents the Login Page completely.
Important design rule:
Page class should never contain assertions
It should only contain page-related actions
Assertions should be in step definitions or test classes.
5. LoginSteps.java (Step Definitions)
This class connects feature file steps to Java implementation.
Annotations used:
@Before
@Given
@When
@Then
@After
Flow:
Initialize browser
Navigate to login page
Enter credentials
Click login
Verify dashboard
Close browser
This maintains clear separation between:
Business steps (feature file)
Technical implementation (step definitions)
Page interactions (page class)
6. TestRunner.java (Cucumber + TestNG)
The TestRunner class:
Executes feature files
Connects glue code
Generates reports
Controls execution behavior
Key attributes:
features → Path of feature files
glue → Path of step definitions
plugin → Reporting configuration
monochrome → Clean console output
This enables BDD-style execution with TestNG support.
7. TestNG.xml (Optional Execution)
TestNG.xml allows:
Suite-level execution
Multiple runner classes
Group execution
Parallel execution control
Though optional, it is helpful in enterprise frameworks.
How the Complete Flow Works
Let’s understand execution flow:
TestRunner starts execution.
Cucumber reads login.feature.
Step definitions get triggered.
PlaywrightFactory initializes browser.
LoginPage methods perform actions.
TestNG validates assertion.
Browser closes.
Report gets generated.
This is a professional-level automation architecture.
Best Practices for Page Object Model in Playwright
To make your framework more robust:
1. Use Proper Locators
Prefer:
data-testid
role selectors
text selectors
Avoid unstable XPath.
2. Use Constructor Injection
Pass Page object via constructor (as shown in example).
3. Avoid Hardcoding URLs
Store URLs in config files.
4. Use Base Page Class
Create a BasePage with common methods like:
waitForElement
click
fill
scroll
Then extend it in all page classes.
5. Add Logging
Use logging framework to track execution steps.
Real-World Importance of POM
In real-time IT projects:
Applications have 100+ pages
Hundreds of test scenarios
Frequent UI changes
Without POM:
Maintenance becomes nightmare
Tests break frequently
Code duplication increases
With POM:
Clean structure
Easy debugging
Faster execution
Better team collaboration
Is Page Object Model Mandatory in Playwright?
No, but it is highly recommended.
For small scripts, you may skip it.
For professional automation frameworks, POM is considered a best practice.
Who Should Learn Page Object Model?
Automation Testers
SDET Engineers
QA Engineers
Software Developers
Freshers preparing for interviews
Anyone learning Playwright with Java
Since you are already working with automation topics and preparing technical content, mastering POM will significantly improve your framework design skills.
Conclusion
The Page Object Model (POM) is one of the most powerful design patterns in test automation. When combined with Playwright, Cucumber, and TestNG, it creates a highly scalable and maintainable automation framework.
In this guide, we covered:
What is POM
Why use POM in Playwright
Benefits of Page Object Model
Complete framework structure
OrangeHRM login automation example
Best practices
If you want to build a professional automation framework, always follow the Page Object Model design pattern.
Suggested Posts:
1. Handle IFrames in Playwright
2. Automate Login Page in Playwright
3. Comma Selectors in Playwright
4. Handle Alerts in Playwright
5. How to Show Visible Elements in Playwright