Page Object Model with Playwright: separating scenarios from page details
Collect locators and page interactions in one place, keep scenarios readable, and understand the limits of this pattern.
A concise English portfolio adaptation of Kazım Şahin's Turkish Medium article. The code below is illustrative; it was not taken from a project repository or a test run.
What should happen when a locator changes?
When many tests select the same page area directly, an interface change spreads across every test file. This maintenance cost is the starting point of the Medium article: separate the intent of the test from page-level details.
Page Object Model collects a page or component's locators and user actions in one object. A test can then describe the behavior it performs instead of the CSS selector it clicks. This structure does not guarantee that every UI change can be fixed in one file; scenarios may also need updates depending on the change.
The responsibility of a page object
A Page Object knows how to reach page fields and perform repeated interactions. The example uses user-visible labels and button names, which also aligns with current Playwright locator guidance.
import type { Locator, Page } from "@playwright/test";
export class LoginPage {
readonly email: Locator;
readonly password: Locator;
readonly submit: Locator;
constructor(page: Page) {
this.email = page.getByLabel("Email");
this.password = page.getByLabel("Password");
this.submit = page.getByRole("button", { name: "Sign in" });
}
async submitCredentials(email: string, password: string) {
await this.email.fill(email);
await this.password.fill(password);
await this.submit.click();
}
}This is not production code or output from an executed test.
Keep the assertion visible in the scenario
While the page object abstracts the action, the test should state the expected result clearly. Filling a sign-in form and confirming that a session was actually created are different responsibilities. Visible expectations make failures easier to interpret.
The article's reuse and readability goals do not automatically mean a higher pass rate or measured time savings. Those claims require comparable runs.
How this appears in the public projects
The Automation Exercise repository separates pages from positive and negative test folders. The e-bebek project separates Gherkin scenarios, step definitions, and Page Object files. These are reviewable code examples of the same design separation.
The cart price and session timing examples in the e-bebek README also show a limit: Page Object structure alone does not resolve an incorrect price assumption or asynchronous product behavior. Observation, suitable assertions, and run isolation must also be designed.
- Collect locators and repeated interactions in a page or component layer.
- Assert the expected behavior explicitly in the test scenario.
- When product behavior changes, reassess both page code and the test assumption.
Article and technical references
The original Turkish Medium article “Playwright ile Page Object Model (POM): Daha Yapılandırılmış ve Bakımı Kolay Testler” was published on October 29, 2024. This page is its concise English portfolio adaptation.