Implementation of Page Object Model in Playwright

















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):

page.fill("#username", "admin"); page.fill("#password", "admin123"); page.click("#login");

We do this (clean practice):

loginPage.enterUsername("admin"); loginPage.enterPassword("admin123"); loginPage.clickLogin();

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:

"#button[type='submit']"

New:

"button.oxd-button"

You only change it in LoginPage.java, not in every test file.


3. Readability

Test scripts become business-readable:

loginPage.login("admin", "admin123");

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:

<dependencies> <!-- Playwright --> <dependency> <groupId>com.microsoft.playwright</groupId> <artifactId>playwright</artifactId> <version>1.44.0</version> </dependency> <!-- Cucumber --> <dependency> <groupId>io.cucumber</groupId> <artifactId>cucumber-java</artifactId> <version>7.16.1</version> </dependency> <dependency> <groupId>io.cucumber</groupId> <artifactId>cucumber-testng</artifactId> <version>7.16.1</version> </dependency> <!-- TestNG --> <dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>7.9.0</version> <scope>test</scope> </dependency> </dependencies>

These dependencies allow integration between Playwright, Cucumber, and TestNG.


2. Feature File (login.feature)

Feature files are written using Gherkin syntax.

Feature: Login Feature Scenario: Successful Login Given User is on login page When User enters username "admin" and password "admin123" Then User should see the dashboard page

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:

  1. Initialize browser

  2. Navigate to login page

  3. Enter credentials

  4. Click login

  5. Verify dashboard

  6. 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:

  1. TestRunner starts execution.

  2. Cucumber reads login.feature.

  3. Step definitions get triggered.

  4. PlaywrightFactory initializes browser.

  5. LoginPage methods perform actions.

  6. TestNG validates assertion.

  7. Browser closes.

  8. 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

No comments:

Post a Comment