Page Transactions and Page Object Model

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.

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

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.

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

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:

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

Use:

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:

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