Page object model
A reusable wrapper that keeps a page's selectors and common browser actions out of every individual end-to-end test.
What it is
A page object model wraps a page or meaningful region of a UI in a reusable object. Instead of every test knowing the email field's locator and the submit sequence, a LoginPage exposes fillCredentials and submit methods plus the few locators tests need to assert on. The Selenium community originated the pattern and Martin Fowler wrote it up as PageObject; Playwright supports the same shape with its Page and Locator APIs.
Reach for it when several end-to-end tests repeat the same selectors or multi-step interaction. Keep the object aligned with user-facing areas, such as CheckoutPage or CartPanel, and prefer getByRole and getByLabel inside it. Then a label or DOM change gets fixed once instead of across twenty test files.
Gotcha: a giant AppPage with every action hides what tests actually do and becomes harder to change than the duplication it replaced. Do not wrap one-off interactions, and keep most assertions in the test so the expected behavior remains visible. Compose small page and component objects instead of building an inheritance tree.
Ask AI for it
Refactor these Playwright tests into a TypeScript page object model. Create a CheckoutPage class that receives Playwright's Page in its constructor, stores getByRole and getByLabel locators, and exposes small methods for addShippingAddress, chooseDelivery, and placeOrder. Keep assertions in the test files, preserve auto-waiting, avoid CSS selectors and fixed timeouts, and compose a CartPanel object instead of inheriting from a base page.