Page Object Model with AI: Design a Clean Playwright Framework

One test is easy. Two hundred tests with copied locators are painful. A framework keeps them tidy, and AI can do much of the typing. In this lesson you will use the Page Object Model with AI, while you stay in charge of the design decisions that matter.

📖 What You’ll Learn

  • What the Page Object Model is
  • A simple framework folder structure
  • How to refactor with AI in small steps
  • Which design decisions should stay with you

💡 What Is the Page Object Model?

Explain Like I’m 5: Page Objects

Imagine: A TV remote has one Volume button. You do not open the TV and touch the wires every time.

What it really means: A page object keeps a page’s locators and actions in one place.

In testing: When a button changes, you fix one line and not fifty tests.


🔍 A Simple Page Object

Here is a page object for our Automation Practice Page.

import type { Locator, Page } from '@playwright/test';

export class PracticePage {
  readonly page: Page;
  readonly loadSuccessButton: Locator;
  readonly loaderMessage: Locator;

  constructor(page: Page) {
    this.page = page;
    this.loadSuccessButton = page.getByRole('button', { name: 'Load Success' });
    this.loaderMessage = page.locator('#loader');
  }

  async goto(): Promise<void> {
    await this.page.goto('https://sqatools.in/automation-practice-page/');
  }

  async loadSuccess(): Promise<void> {
    await this.loadSuccessButton.click();
  }
}

And here is the test that uses it:

import { test, expect } from '@playwright/test';
import { PracticePage } from '../pages/practice-page';

test('Load Success shows the success message', async ({ page }) => {
  const practicePage = new PracticePage(page);

  await practicePage.goto();
  await practicePage.loadSuccess();
  await expect(practicePage.loaderMessage).toHaveText('Data loaded successfully!');
});

The test now reads like a set of steps. In this course we keep assertions in the tests, so the page object does not hide what is being checked.


🧩 A Simple Folder Structure

Explain Like I’m 5: A Tidy Bedroom

Imagine: Socks go in one drawer and books go on the shelf. You can find things without searching the whole room.

What it really means: Each kind of file gets one clear place.

In testing: Pages, tests, data and helpers stay separate.

tests/
  practice-page.spec.ts
pages/
  practice-page.ts
test-data/
  users.json
fixtures/
  pages.ts
playwright.config.ts

See Framework Folder Structure for a fuller layout.


🛠️ How to Use the Page Object Model with AI

Explain Like I’m 5: Moving House

Imagine: You move one box at a time and check that nothing broke. You do not throw the whole house onto a truck.

What it really means: Refactor a little, test, and then continue.

In testing: Convert one page and its tests before starting the next.

Ask AI to refactor one page at a time. Run the tests before and after each change. A refactor should change the structure, and it should not change what the tests prove.

Refactoring must keep behaviour

Compare your test count and results before and after. If assertions disappear, reject the change.


📌 Decisions That Stay With You

AI tends to add layers because they look professional. Too many layers make simple tests hard to read.

DecisionA good question to ask
Base classesDo we really share behaviour here?
HelpersIs it used more than once?
Assertions in page objectsDoes our team allow this?
FixturesDoes this remove real repeated setup?
Test dataWhere should it live, and who owns it?

Start simple. Add structure only when repetition causes a real problem. Our Page Object Model lesson explains the pattern in detail.


🌍 Real-Life Example: Over-Engineering

A tester asks AI to “create an enterprise framework” for six tests. The answer has base pages, factories, wrappers and a logging layer. It looks impressive, but a new teammate cannot follow it. The tester instead asks for one page object and one fixture. The result is smaller and easier to maintain.


🧪 Try It Yourself

  1. Take the two tests from Lesson 24.
  2. Commit your project.
  3. Run the prompt below.
  4. Review the diff, and confirm that the assertions are unchanged.
  5. Run the tests, and compare the results.

📋 Ready-to-Copy Prompt

You are a senior test automation engineer. Refactor these Playwright
TypeScript tests to use the Page Object Model.

Current tests:
[paste tests]

Rules:
- Create one page object only for the page used in these tests.
- Keep all assertions in the test file.
- Do not change what any test checks.
- Do not add base classes, wrappers or new packages.
- Keep the same locators unless one is clearly unstable.

Show the new folder structure and full file contents. Then list
anything you changed apart from moving code.

⚠️ Common Mistakes

  • Asking AI for a huge framework on day one
  • Refactoring many pages in one step
  • Hiding important assertions inside helpers
  • Adding base classes with no shared behaviour
  • Skipping the before-and-after test run

🎯 Key Takeaways

  • Page objects keep locators and actions in one place.
  • A simple folder structure is easier to maintain.
  • Refactor one page at a time, and check the results.
  • Design decisions remain a human responsibility.

🎤 Interview Questions

1. What is the Page Object Model?

Model answer: It is a design pattern that places a page’s locators and actions in a dedicated class. Tests call those methods, so a UI change usually needs an update in only one place.

2. Should assertions be placed inside page objects?

Model answer: Teams differ. I usually keep assertions in tests so that the test clearly shows what it verifies. Simple page-level checks may be acceptable if the team agrees on that convention.

3. How would you use AI to refactor a test framework?

Model answer: I would work in small steps, starting with one page. I would give it clear rules, run the tests before and after, and review the diff to confirm behaviour and assertions did not change.

4. What is over-engineering in test automation?

Model answer: It means adding layers or abstractions before they solve a real problem. This makes tests harder to read and maintain, so I add structure only when repetition or complexity justifies it.

5. How are fixtures useful in Playwright?

Model answer: Fixtures provide reusable setup and teardown for tests, such as creating page objects or signed-in users. They reduce repeated code and give each test the resources it needs.


📝 Assignment

Create page objects for two sections of the practice page. Add a fixture that provides one of them, then write two tests. Ask a friend to read a test and explain what it does without opening the page object.


❓ FAQ

Are page objects required in Playwright?

No. Small projects can work well without them. They become useful as repeated locators and actions grow.

Should I use fixtures or page objects?

They work well together. Page objects describe the page, and fixtures prepare what each test needs.


🚀 Next Steps

Well done on finishing this lesson. Complete the assignment, then continue with Migrate Selenium to Playwright with AI: A Safe Step-by-Step Plan.