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.
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.
a_t48 1 hours ago [-]
I'm not really a UI guy, but isn't this MVC (or some subset)?
vasusen 20 minutes ago [-]
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.
serial_dev 1 hours ago [-]
Page object is a useful model for writing maintainable tests
Rendered at 06:48:35 GMT+0000 (Coordinated Universal Time) with Vercel.
--
1: https://playwright.dev/docs/pom
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.