Why POM organizes test code in Selenium Python - Why It Works This Way

Overview - Why POM organizes test code

What is it?

Page Object Model (POM) is a way to organize test code by creating separate classes for each page or part of a web application. Each class holds the locators and methods to interact with that page. This keeps test scripts clean and easy to read because they use these page classes instead of raw code. It helps testers write and maintain tests faster and with fewer errors.

Why it matters

Without POM, test code becomes messy and hard to fix when the website changes. Testers would have to update many places in the code, wasting time and risking mistakes. POM solves this by centralizing page details, so changes happen in one place. This saves effort, reduces bugs, and makes tests more reliable, which is crucial for delivering quality software quickly.

Where it fits

Before learning POM, you should understand basic Selenium commands and how to locate elements on a web page. After POM, you can learn advanced test design patterns like the Screenplay pattern or integrate POM with test frameworks for better reporting and parallel execution.

Mental Model

Core Idea

POM organizes test code by separating page details into classes, making tests easier to write, read, and maintain.

Think of it like...

Think of POM like a remote control for a TV: instead of pressing buttons directly on the TV (messy and hard), you use the remote (organized and simple) to control it. The remote hides the complex details and gives you easy commands.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│   Test Case   │─────▶│  Login Page   │─────▶│  Home Page    │
│  (uses page   │      │  (locators &  │      │  (locators &  │
│   classes)    │      │   methods)    │      │   methods)    │
└───────────────┘      └───────────────┘      └───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Test Code Structure

Concept: Tests interact with web pages by finding elements and performing actions.

In Selenium, you write code to find buttons, input boxes, and links using locators like ID or XPath. Then you tell the browser to click or type. Without organization, this code mixes test logic and page details.

Result

Test scripts become long and hard to read because they mix what to test with how to find elements.

Knowing that test code mixes two concerns helps see why separating them improves clarity.

2

Foundation

What is Page Object Model (POM)?

Concept: POM separates page details into classes to keep test code clean.

Each web page gets a class with locators and methods like 'login' or 'click_button'. Tests call these methods instead of raw Selenium commands.

Result

Tests become shorter and easier to understand because they use simple method calls.

Separating page details into objects reduces duplication and makes tests more readable.

3

Intermediate

How POM Improves Maintenance

🤔Before reading on: do you think changing a button's locator requires updating all tests or just one place? Commit to your answer.

Concept: POM centralizes locators so changes happen in one class, not many tests.

If a button's ID changes, you update it only in the page class. All tests using that method automatically use the new locator.

Result

Fixing broken tests becomes faster and less error-prone.

Understanding this prevents wasting time fixing many tests for one page change.

4

Intermediate

Using Methods to Encapsulate Actions

🤔Before reading on: do you think tests should know how to click a button or just ask the page to do it? Commit to your answer.

Concept: POM uses methods to hide how actions happen, exposing only what tests need.

Instead of tests calling 'find_element' and 'click', they call 'login_page.click_login_button()'. The method handles details.

Result

Tests focus on what to test, not how to do it, improving readability and reducing errors.

Knowing this helps write tests that are easier to understand and change.

5

Advanced

Organizing Large Projects with POM

🤔Before reading on: do you think one class per page is enough for big apps or do you need more structure? Commit to your answer.

Concept: In big projects, POM classes can be grouped by features or modules for better organization.

You can create folders for login, dashboard, settings, each with page classes. This keeps code manageable as it grows.

Result

Large test suites stay organized and scalable.

Understanding project structure helps maintain tests as applications grow.

6

Expert

Avoiding Common POM Pitfalls

🤔Before reading on: do you think putting assertions inside page classes is a good idea? Commit to your answer.

Concept: Page classes should only handle page actions, not test assertions or logic.

Mixing assertions in page classes makes them less reusable and harder to maintain. Keep assertions in test scripts.

Result

Cleaner separation of concerns and more flexible tests.

Knowing this prevents design mistakes that reduce POM benefits.

Under the Hood

POM works by creating objects that represent web pages. Each object stores locators as variables and exposes methods that perform actions using Selenium commands. When tests call these methods, the page object uses the stored locators to find elements and interact with them. This hides the complexity of element location and interaction from the test code.

Why designed this way?

POM was designed to solve the problem of duplicated and fragile test code. Before POM, tests had raw locators scattered everywhere, making maintenance hard. By grouping locators and actions in page classes, POM reduces duplication and isolates changes. Alternatives like writing all code in tests were rejected because they led to messy, brittle tests.

┌───────────────┐
│   Test Code   │
│  calls methods│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Page Object   │
│ - locators    │
│ - methods     │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Selenium Web  │
│Driver actions │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think POM means writing all test code inside page classes? Commit to yes or no.

Common Belief: POM means putting all test steps and assertions inside page classes.

Reality: Page classes should only contain locators and methods to interact with the page, not test logic or assertions.

Why it matters: Mixing test logic in page classes makes tests harder to read, reuse, and maintain.

Quick: Do you think POM eliminates the need to update tests when UI changes? Commit to yes or no.

Common Belief: Once POM is used, tests never break when the UI changes.

Reality: POM reduces the places to update but you still must fix locators or methods in page classes when UI changes.

Why it matters: Assuming no updates are needed leads to ignoring maintenance and broken tests.

Quick: Do you think POM is only useful for big projects? Commit to yes or no.

Common Belief: POM is only worth using in large, complex test suites.

Reality: POM benefits even small projects by improving clarity and reducing duplication.

Why it matters: Skipping POM early can cause messy code that grows harder to maintain.

Quick: Do you think using POM means tests run slower? Commit to yes or no.

Common Belief: POM adds extra layers and slows down test execution.

Reality: POM organizes code but does not affect how fast Selenium interacts with the browser.

Why it matters: Misunderstanding this may discourage using POM and miss its maintainability benefits.

Expert Zone

1

Page classes should avoid storing test data; keep data separate to maintain flexibility.

2

Using lazy loading for elements in page classes can improve performance and reduce stale element errors.

3

Combining POM with design patterns like Factory or Singleton can improve object management in large suites.

When NOT to use

POM is less effective for very simple or one-off tests where overhead is unnecessary. Alternatives like direct scripting or lightweight helper functions may be better for quick checks or prototypes.

Production Patterns

In real projects, POM is combined with test frameworks like pytest, using fixtures to instantiate page objects. Teams often create base page classes for shared methods and use inheritance to reduce duplication.

Connections

Single Responsibility Principle (SRP)

POM applies SRP by giving each page class one job: managing its page elements and actions.

Understanding SRP helps grasp why separating page logic improves code quality and maintainability.

Object-Oriented Programming (OOP)

POM uses OOP concepts like classes and methods to model web pages as objects.

Knowing OOP basics clarifies how POM structures code and enables reuse.

Human Factors in User Interface Design

POM reflects how users think of pages as separate screens with actions, mirroring UI design principles.

Recognizing this connection helps testers design page classes that align with user workflows, improving test clarity.

Common Pitfalls

#1 Mixing test assertions inside page classes.

Wrong approach:

class LoginPage:
def verify_login_success(self):
assert 'Welcome' in driver.page_source # wrong: assertion inside page class

Correct approach:

class LoginPage:
def is_login_successful(self):
return 'Welcome' in driver.page_source

# In test code:
assert login_page.is_login_successful() # assertion in test

Root cause:

Confusing page responsibilities with test validation leads to poor separation of concerns.

#2 Hardcoding locators directly in test scripts.

Wrong approach:

driver.find_element(By.ID, 'submit').click() # locator in test code

Correct approach:

class SubmitPage:
submit_button = (By.ID, 'submit')
def click_submit(self):
driver.find_element(*self.submit_button).click()

Root cause:

Not using POM leads to duplicated locators and fragile tests.

#3 Creating one huge page class for the entire app.

Wrong approach:

class AppPage:
def login(self): ...
def search(self): ...
def checkout(self): ... # all pages mixed

Correct approach:

class LoginPage: ...
class SearchPage: ...
class CheckoutPage: ... # separate classes per page

Root cause:

Ignoring modular design causes hard-to-maintain code.

Key Takeaways

Page Object Model organizes test code by separating page details into classes with locators and methods.

This separation makes tests easier to read, write, and maintain by hiding page complexity from test logic.

POM centralizes changes, so updating locators or actions happens in one place, reducing errors and effort.

Proper POM design keeps page classes focused on page interactions, leaving assertions and test logic to test scripts.

Using POM improves test code quality and scalability, especially as projects grow in size and complexity.