DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Solid Testing Strategies for Salesforce Releases
  • Running and Debugging Tests With Playwright UI Mode
  • Working With Vision AI to Test Cloud Applications
  • Storybook: A Developer’s Secret Weapon

Trending

  • Analyzing “java.lang.OutOfMemoryError: Failed to create a thread” Error
  • Enhancing Security With ZTNA in Hybrid and Multi-Cloud Deployments
  • Understanding and Mitigating IP Spoofing Attacks
  • Beyond Microservices: The Emerging Post-Monolith Architecture for 2025
  1. DZone
  2. Coding
  3. Frameworks
  4. Page Transactions and Page Object Model

Page Transactions and Page Object Model

A structured comparison of Page Transactions and the Page Object Model, with the pros and cons of each pattern and tips for migrating from one to the other.

By 
Douglas Cardoso user avatar
Douglas Cardoso
·
Feb. 17, 25 · Analysis
Likes (1)
Comment
Save
Tweet
Share
1.6K Views

Join the DZone community and get the full member experience.

Join For Free

Recently, I wrote an article on Page Transactions as a new approach to test automation, focusing on simplicity, readability, and flexibility. Now, I present a structured comparison of Page Transactions (PT) and Page Object Model (POM), explaining the pros and cons of each pattern. Finally, I will give some tips on migrating from POM to PT in simple steps.

To those who are not familiar with POM, in a nutshell, it is a design pattern used in testing automation where the objects on a UI page are represented as methods in a class and where each class represents the UI page itself.

The comparison takes into account aspects like maintainability, reusability, readability, and simplicity. Let's start with POM, a popular test automation pattern, and its advantages and disadvantages.

Page Object Model

Code Maintainability

Advantages

  • Separates locators from tests
  • Easy to update elements

Disadvantages

  • Still tightly coupled with page structure
  • If UI changes, all affected pages must be updated

Reusability

Advantages

  • Page classes can be reused across multiple tests

Disadvantages

  • Interactions are page-specific, not user-flow-based

Readability and Simplicity

Advantages

  • Test cases look clean with method calls

Disadvantages

  • Requires writing multiple classes for different pages, which can add complexity

Scalability

Advantages

  • Works well for large projects with many pages

Disadvantages

  • Harder to manage when dealing with workflows spanning multiple pages

Test Maintenance Effort

Advantages

  • If a locator changes, it only needs to be updated in one place

Disadvantages

  • If the user workflow changes, tests might need significant updates

Suitability for UI testing

Advantages

  • Well-suited for UI automation with Selenium and similar tools

Disadvantages

  • Not ideal for non-UI scenarios (e.g., REST API testing)

Now, let's talk about Page Transactions.

Page Transactions

Code Maintainability

Advantages

Transactions focus on user actions rather than elements, reducing maintenance

Disadvantages

Requires a different mindset for those used to POM

Reusability

Advantages

Highly reusable since transactions are user-action-based

Disadvantages

If the UI structure changes drastically, transactions might need updates

Readability and Simplicity

Advantages

  • Tests read like human instructions, improving clarity
  • Reduces WebDriver calls in the test script

Disadvantages

  • Requires defining multiple transaction classes for different actions

Scalability

Advantages

  • Works well for large applications, especially where user flows span multiple pages

Disadvantages

  • Slightly more setup is needed compared to POM

Test Maintenance Effort

Advantages

  • Less maintenance is required since tests are written based on actions rather than UI elements

Disadvantages

  • If a transaction is reused across many tests, fixing one issue could impact multiple tests

Suitability for UI testing

Advantages

  • Works for UI, API, and asynchronous testing

Disadvantages

  • Less common in traditional UI automation frameworks

Analysis

PT focuses on user workflows, making it more maintainable and scalable. It allows for better test organization and is more suitable for different types of automation (Web UI, API, Desktop UI). Tests written in PT are more readable, making them accessible to non-technical stakeholders. If your project involves complex user workflows across multiple pages, Page Transaction is the better approach.

POM is still a great choice for teams already familiar with traditional UI testing methods and provides a structured way to manage page elements. If you need simple UI structure representation, POM works well.

So, no pattern is best or worst. It depends on the characteristics of a given project. However, if the project fits better with the PT pattern but is already implemented in POM, it is possible to migrate from POM to PT following these tips.

Tips for Migrating from POM to PT

Moving from POM to PT requires shifting from page-centric automation to user action-centric automation. Below are key steps and examples to help with the transition.

1. Identify User Transactions

In POM, page objects represent pages. In PT, it focuses on transactions like Login, Logout, Submit Form, Change Language, Navigate to a Page. Instead of writing separate methods for every element on a page, create classes for each transaction.

2. Convert POM Methods to PT Transactions

See below a POM example (before migration). The test login to a page, informs the user and password of a user, and checks if the Dashboard page is displayed. There is a LoginPage class which hosts the methods to interact with the components of the page, like username field.

Python
 
from selenium.webdriver.common.by import By

class LoginPage:
    def __init__(self, driver):
        self.driver = driver
        self.username = (By.ID, "username")
        self.password = (By.ID, "password")
        self.login_button = (By.ID, "login")

    def enter_username(self, user):
        self.driver.find_element(*self.username).send_keys(user)

    def enter_password(self, pwd):
        self.driver.find_element(*self.password).send_keys(pwd)

    def click_login(self):
        self.driver.find_element(*self.login_button).click()
Python
 
def test_login():
    driver = webdriver.Chrome()
    login_page = LoginPage(driver)

    login_page.enter_username("user1")
    login_page.enter_password("password1")
    login_page.click_login()

    assert "Dashboard" in driver.title


Here is a PT example (after migration). Now, the LoginTransaction class represents the whole login action, which adds the user name and password and submits them.

Python
 
from guara.transaction import AbstractTransaction

class LoginTransaction(AbstractTransaction):
    def __init__(self, driver):
        super().__init__(driver)

    def do(self, username, password):
        self._driver.find_element(By.ID, "username").send_keys(username)
        self._driver.find_element(By.ID, "password").send_keys(password)
        self._driver.find_element(By.ID, "login").click()
        return self._driver.title
Python
 
from guara.transaction import Application
from guara import it
from selenium import webdriver

def test_login():
    driver = webdriver.Chrome()
    app = Application(driver)

    app.at(LoginTransaction, username="user1", password="password1").asserts(
      it.Contains, "Dashboard"
    )


Benefits of the PT Approach

  • Less boilerplate code, as there is no need for page-specific methods in tests
  • Readable test cases once tests describe actions in plain English
  • Easier maintenance as UI changes don’t break all related test methods

3. Additional Refactoring for Other Pages

For example, changing Language Transaction, instead of:

Python
 
class HomePage:
    def click_language_button(self):
        self.driver.find_element(By.ID, "language").click()


Use:

Python
 
class ChangeLanguageTransaction(AbstractTransaction):
    def __init__(self, driver):
        super().__init__(driver)

    def do(self, language):
        self._driver.find_element(By.ID, f"lang-{language}").click()
        return self._driver.find_element(By.TAG_NAME, "body").text


Test case:

Python
 
app.at(ChangeLanguageTransaction, language="pt").asserts(
  it.Contains, "Página inicial"
)


4. Gradual Migration Strategy

  • Start with frequently changing tests
  • Convert one transaction at a time
  • Keep old POM code until full migration is complete

Conclusion

PT is a new pattern, but it demonstrates good qualities when compared to POM, which is a widely used pattern in test automation. In some situations, PT fits better and can be used as an alternative to POM.

References

  • Page Transactions: A New Approach to Test Automation
UI Object (computer science) Testing

Published at DZone with permission of Douglas Cardoso. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Solid Testing Strategies for Salesforce Releases
  • Running and Debugging Tests With Playwright UI Mode
  • Working With Vision AI to Test Cloud Applications
  • Storybook: A Developer’s Secret Weapon

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!