Page Object Models trade off clarity for encapsulation. Concrete example [1]. They can make tests look "cleaner" but often obscure what's actually happening. For example:
await page.getStarted(); // what does this actually do?
The second version is explicit and self-documenting. Tests don't always benefit from aggressive DRY, but I've seen teams adopt POMs to coordinate between SDETs and SWEs.
It is quite popular in testing circles to write e2e tests that are easier to maintain.
However, in practice I have found it to be quite useless due to the time it takes to write good page objects. QA teams usually rely on a complete POM before writing tests on it. I used to joke that by the time my team was done shipping a page object model, our product team would have changed the entire product again.
Page Object Models trade off clarity for encapsulation. Concrete example [1]. They can make tests look "cleaner" but often obscure what's actually happening. For example:
vs The second version is explicit and self-documenting. Tests don't always benefit from aggressive DRY, but I've seen teams adopt POMs to coordinate between SDETs and SWEs.--
1: https://playwright.dev/docs/pom
This is honestly the main reason I prefer Playwright to Cypress. Playwright leans heavily into using POs, while for some reason Cypress doesn't.
So in almost every project the Cypress tests are a procedural mess, while the Playwright tests are mostly well structured.
I know that Cypress has other patterns for dealing with this but they never seem to get applied.
I'm not really a UI guy, but isn't this MVC (or some subset)?
It is quite popular in testing circles to write e2e tests that are easier to maintain. However, in practice I have found it to be quite useless due to the time it takes to write good page objects. QA teams usually rely on a complete POM before writing tests on it. I used to joke that by the time my team was done shipping a page object model, our product team would have changed the entire product again.
Page object is a useful model for writing maintainable tests