Page Object Model in Cypress - Deep Dive

Overview - Page Object Model in Cypress

What is it?

Page Object Model (POM) in Cypress is a way to organize test code by separating page details from test logic. It means creating objects that represent web pages or parts of pages, with methods to interact with them. This helps tests stay clean, easy to read, and simple to maintain. Instead of repeating selectors and actions, you reuse page objects.

Why it matters

Without POM, test code can become messy and hard to fix when the website changes. POM solves this by centralizing page details, so updates happen in one place. This saves time, reduces errors, and makes tests more reliable. It also helps teams work together better because the test structure is clear and consistent.

Where it fits

Before learning POM, you should know basic Cypress commands and how to write simple tests. After POM, you can explore advanced test design patterns, custom commands, and continuous integration setups. POM is a bridge from beginner tests to scalable, professional test suites.

Mental Model

Core Idea

Page Object Model means treating each page as an object with its own actions and elements, so tests use these objects instead of raw selectors.

Think of it like...

It's like having a remote control for your TV instead of pressing buttons directly on the TV. The remote groups all controls in one place, making it easier and cleaner to operate.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Test Code   │──────▶│ Page Object   │──────▶│ Web Page DOM  │
│ (uses methods)│       │ (methods &    │       │ (elements)    │
│               │       │  selectors)   │       │               │
└───────────────┘       └───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Cypress Basic Tests

Concept: Learn how Cypress runs simple tests using commands and selectors.

In Cypress, you write tests that visit pages and interact with elements using commands like cy.visit(), cy.get(), and cy.click(). For example, cy.get('#login').click() finds the login button and clicks it.

Result

You can automate simple user actions and check page behavior.

Knowing how Cypress commands work is essential before organizing them into reusable structures like page objects.

2

Foundation

Selectors and Test Duplication Problems

Concept: Recognize how repeating selectors in tests causes maintenance issues.

If you write cy.get('#username').type('user') in many tests, and the '#username' selector changes, you must update all tests. This duplication leads to errors and wasted time.

Result

Tests become fragile and hard to maintain as the app evolves.

Understanding this problem motivates the need for a better way to manage selectors.

3

Intermediate

Creating Page Objects as Classes

🤔Before reading on: do you think page objects should contain only selectors, or both selectors and actions? Commit to your answer.

Concept: Introduce page objects as classes that hold selectors and methods to interact with page elements.

In Cypress, you can create a class like LoginPage with methods like enterUsername(), enterPassword(), and clickLogin(). Each method uses cy.get() internally. Tests then call these methods instead of raw commands.

Result

Tests become shorter and more readable, using page object methods.

Knowing that page objects combine selectors and actions helps keep tests clean and focused on behavior, not details.

4

Intermediate

Using Page Objects in Cypress Tests

🤔Before reading on: do you think tests should create new page object instances each time, or reuse one instance? Commit to your answer.

Concept: Learn how to import and use page objects inside Cypress test files.

You import the page object class, create an instance in a test, and call its methods. For example, const login = new LoginPage(); login.enterUsername('user'); login.clickLogin(); This separates test steps from page details.

Result

Tests are easier to write and maintain, with clear separation of concerns.

Understanding how to use page objects in tests unlocks better test organization and reuse.

5

Intermediate

Organizing Page Objects for Large Projects

🤔Before reading on: do you think all page objects should be in one file or split by page? Commit to your answer.

Concept: Learn best practices for structuring page objects in folders and files for scalability.

In bigger projects, each page object lives in its own file inside a 'pages' folder. This keeps code modular and easy to find. You can also create base page classes for shared methods.

Result

The test codebase stays organized and scalable as it grows.

Knowing how to structure page objects prevents chaos in large test suites.

6

Advanced

Handling Dynamic Elements in Page Objects

🤔Before reading on: do you think page objects should hardcode all selectors or handle dynamic selectors? Commit to your answer.

Concept: Learn techniques to manage selectors that change or depend on data.

Page objects can have methods that accept parameters to build selectors dynamically. For example, getUserRow(username) returns cy.get(`tr[data-user='${username}']`). This makes page objects flexible for dynamic content.

Result

Tests can handle complex pages with changing elements reliably.

Understanding dynamic selectors in page objects increases test robustness.

7

Expert

Avoiding Common POM Pitfalls in Cypress

🤔Before reading on: do you think page objects should contain assertions or only actions? Commit to your answer.

Concept: Explore advanced best practices and common mistakes when using POM in Cypress.

Page objects should focus on actions and element access, not assertions. Assertions belong in tests to keep responsibilities clear. Also, avoid over-abstracting which can hide test intent. Use custom commands for repeated Cypress logic instead of bloated page objects.

Result

Tests remain clear, maintainable, and easy to debug.

Knowing these boundaries prevents confusing test code and hard-to-find bugs.

Under the Hood

Page Object Model works by encapsulating selectors and actions inside objects or classes. When a test calls a method on a page object, it triggers Cypress commands that interact with the browser DOM. Cypress queues these commands and runs them asynchronously, managing retries and waits automatically. The page object acts as a clean interface hiding the raw selectors and Cypress commands from the test logic.

Why designed this way?

POM was designed to reduce duplication and improve maintainability in UI tests. Early UI tests were brittle and hard to update because selectors were scattered. By grouping selectors and actions, POM centralizes changes. Cypress supports this pattern naturally because its commands are chainable and asynchronous, making page objects a perfect abstraction layer.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Test Code   │──────▶│ Page Object   │──────▶│ Cypress Cmds  │
│ (calls method)│       │ (methods call │       │ (interact with│
│               │       │  cy.get, etc) │       │  DOM elements)│
└───────────────┘       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do page objects contain test assertions? Commit to yes or no before reading on.

Common Belief: Page objects should include assertions to verify page state.

Reality: Page objects should only contain selectors and actions; assertions belong in test files.

Why it matters: Mixing assertions into page objects blurs responsibilities and makes tests harder to understand and maintain.

Quick: Is it best to create a new page object instance for every test? Commit to yes or no before reading on.

Common Belief: Each test should create a fresh page object instance to avoid state issues.

Reality: Page objects are usually stateless wrappers; reusing instances or creating new ones per test both work, but over-instantiation is unnecessary.

Why it matters: Unnecessary object creation can clutter code and confuse test flow without benefits.

Quick: Should page objects hide all Cypress commands including waits and retries? Commit to yes or no before reading on.

Common Belief: Page objects should hide all Cypress internals to keep tests clean.

Reality: While page objects hide selectors, Cypress commands like waits and retries are automatic and should not be hidden in ways that confuse test timing.

Why it matters: Misusing page objects to hide Cypress behavior can cause flaky tests and debugging difficulties.

Quick: Can page objects solve all test maintenance problems? Commit to yes or no before reading on.

Common Belief: Using POM guarantees tests never break when UI changes.

Reality: POM reduces duplication but cannot prevent all breakages; selectors still need updates if UI changes significantly.

Why it matters: Over-relying on POM can lead to complacency and fragile tests if selectors are not maintained properly.

Expert Zone

1

Page objects should avoid storing state or data; they represent the page structure and actions only.

2

Combining POM with Cypress custom commands can create powerful reusable test utilities without bloating page objects.

3

Over-abstracting page objects by creating too many tiny methods can hide test intent and make debugging harder.

When NOT to use

POM is less useful for very simple or one-off tests where abstraction adds unnecessary complexity. In such cases, direct Cypress commands are clearer. Also, for API or unit tests, POM is irrelevant; use other design patterns instead.

Production Patterns

In real projects, teams organize page objects by feature folders, use base page classes for shared logic, and combine POM with data-driven testing. They keep page objects focused on UI interactions and put assertions and test data in separate layers for clarity.

Connections

Single Responsibility Principle (SRP)

POM applies SRP by separating page structure from test logic.

Understanding SRP helps grasp why page objects should only handle UI interactions, keeping tests focused on behavior.

Object-Oriented Programming (OOP)

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

Knowing OOP basics clarifies how page objects encapsulate selectors and actions as reusable objects.

Human Factors in Software Engineering

POM improves code readability and team collaboration by organizing tests clearly.

Recognizing human factors explains why clean test structure reduces errors and speeds up maintenance.

Common Pitfalls

#1 Mixing assertions inside page object methods.

Wrong approach:

class LoginPage {
clickLogin() {
cy.get('#login').click();
cy.get('#welcome').should('be.visible'); // assertion inside page object
}
}

Correct approach:

class LoginPage {
clickLogin() {
cy.get('#login').click();
}
}

// In test file:
loginPage.clickLogin();
cy.get('#welcome').should('be.visible');

Root cause:

Confusing responsibilities leads to harder-to-maintain tests and unclear test failures.

#2 Hardcoding all selectors without parameters for dynamic elements.

Wrong approach:

class UserPage {
getUserRow() {
return cy.get('tr.user-row');
}
}

Correct approach:

class UserPage {
getUserRow(username) {
return cy.get(`tr[data-user='${username}']`);
}
}

Root cause:

Ignoring dynamic content leads to brittle tests that cannot handle variable data.

#3 Creating huge page objects with unrelated methods.

Wrong approach:

class DashboardPage {
openSettings() { ... }
createUser() { ... }
deleteUser() { ... }
logout() { ... }
// too many unrelated actions
}

Correct approach:

class DashboardPage {
openSettings() { ... }
}
class UserManagementPage {
createUser() { ... }
deleteUser() { ... }
}
class Header {
logout() { ... }
}

Root cause:

Not modularizing page objects causes confusion and harder maintenance.

Key Takeaways

Page Object Model organizes test code by representing pages as objects with methods for actions and selectors.

POM reduces duplication and improves test maintainability by centralizing page details.

Page objects should contain only UI interactions, keeping assertions in test files for clear responsibilities.

Proper structuring and handling of dynamic selectors make page objects scalable and robust.

Understanding POM deeply helps build reliable, readable, and maintainable Cypress test suites.