Framework Milestone 3: Page Objects

Why it matters

When the UI changes, a good page layer means you fix one file instead of every test. It's the most common framework question in interviews.

What to build

Page objects. LoginPage, DashboardPage, PoliciesPage and ClaimFormPage for the four-step claim form. Each exposes actions (signIn, searchFor, continue) and reads values (welcomeName, rowCount).
Component objects. A Header with the navigation and sign-out, and a reusable Table for the policy and claim lists (rows, cell text, sorting, paging). Pages that show them hold an instance.
A locator strategy. Prefer IDs and data-testid, then accessible roles and labels, then short CSS. Avoid long XPath and positions like tr[3], which break when the data changes.
Tests that use them. Sign in, filter policies by type, sort by coverage, and check the first row. Then start a claim and check that the form refuses a missing date.

Rules

Tests contain no locators: every element is found inside a page or component object.
Methods that move to another screen return that screen's object, so a test can chain steps.
Decide, and note in your README, whether assertions live in tests or in pages. Both are defensible; mixing them is not.

Hints

Selenium

Keep By locators as fields and find elements when a method runs, not in the constructor: DojoCover redraws screens, and an element found too early goes stale.

Playwright

Store Locator objects as fields: they are lazy, so creating them early is safe. getByRole, getByLabel and getByTestId keep them readable.

These are pointers, not solutions. TestDojo doesn't publish a finished framework: the point is that you build and understand your own.

Done when

No test file contains a locator
The header component is used by at least two page objects
Changing one locator on purpose breaks the tests in one file only
The policy table test filters, sorts and checks rows through the table component
The claim form test checks a validation message through the page object

Ticks are saved in this browser only, for your own tracking.

In an interview

Questions this milestone prepares you for, and what a good answer covers. Answer them in your own words, about your own framework.

What is the Page Object Model, and why use it?: Separating what a test does from how it finds elements, fewer places to change, and readable tests.
Page objects or component objects: when do you use each?: Shared pieces such as headers, tables and dialogs as components reused across pages.
How do you choose locators?: Stable IDs and test IDs first, roles and labels next, and why indexes and long XPath are fragile.
Where do your assertions go?: Your choice and the trade-off: pages stay reusable when tests own the assertions.

Note the decision you made in this milestone and why. Those notes become your README in milestone 9.

Page and component objects