page object model vs locator functions: which to use
Compares page objects with locator functions for test maintainability. Use when choosing test structure. Not for framework choice.
TL;DR
Both encapsulate selectors; page objects group by page, locator functions group by component. For component-based UIs, locator functions (or Playwright fixtures) age better; page objects fit page-based flows.
Error
(Not an error; an architecture decision. The cost of a bad choice: selector changes scattered across tests.)Steps
- Assess the UI: component-based (React/Vue) favors component-scoped helpers; page-based flows favor page objects. Expected: the structure matches the app.
- For Playwright, prefer fixtures and locator helpers over classic page objects. Expected: idiomatic Playwright.
- For Cypress, use custom commands or plain helper modules. Expected: no heavy class hierarchies.
- Keep exactly one place per selector. Expected: a selector change touches one file.
- Review after 3 months: if helpers are bypassed, simplify them. Expected: the abstraction earns its keep.
When to use
- Starting a new suite or restructuring.
- Selector duplication is growing.
When not to use
- Small suites (helpers are overhead).
- You already have a working pattern (do not churn).
Tool compatibility
- Any framework; Playwright fixtures, Cypress commands.
Variant phrasings
Page object model still relevant
Yes for page flows; less so for component UIs.
Test selector encapsulation patterns
The general topic; one place per selector.
Why it happens
Raw selectors in tests duplicate knowledge. Encapsulation centralizes it, but the wrong shape creates its own maintenance burden.
Edge cases
- Deep page-object hierarchies become their own legacy; prefer flat helpers.
- Helpers that hide waits create mystery; keep waiting explicit.
- Generate helpers from components where possible.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_sTUWiCM2suIPo0Sxol-6Sg