I'm confused about why this is on the front page of HN?
movpasd 55 minutes ago [-]
I think this comes back to the idea of having a "UX model" that underlies the user interface, laying out its affordances clearly in code. In a modern application you're going to have complex UX logic and state that's distinct from the domain model as such and that deserves representation in the code.
In an MVC conception, the UX model becomes a top layer of abstraction of the domain model. It's a natural place to be because for modern apps, users expect "more than forms", i.e.: different ways of cutting up the domain data, presented in different ways, ...
This is something that component-based frontend frameworks struggle with a bit: the hierarchical layout of the DOM doesn't always reflect the interrelations in data between parts of a user experience. Prop drilling is just a reflection of this fact and perhaps it's why we're seeing a rise in the use of state stores. It's not really about state, that's just the technical symptom, it's really about providing a way of defining a (in-browser) data model based on the user experience itself rather than the particularities of the UI substrate.
emmanueloga_ 4 hours ago [-]
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.
Each of those lines is 3 to 20 lines of Playwright code. Aggressive DRY is bad, but Page Object Models are usually worth it to reduce duplication and limit churn from UI changes.
kleyd 1 hours ago [-]
It's not a trade-off of clarity just to save developers some extra typing. It's actually improving the clarity by bringing the thing you care about to the foreground: the getting started page having a table of contents with specific items.
In summary: having thing look cleaner at a glance is not helping if you’re (almost) always going to need to do more than glancing
zikani_03 3 hours ago [-]
I am working on a tool[1] to try to make working with playwright a bit more ergonomic and approachable. Sorry to shamelessly plug but I'd love feedback on if it is even a good idea/direction.
Hadn't considered the Page Object Model and will definitely have to consider how to incorporate that for those who want to do things that way.
Well, if you have tests with 100+ lines of such explicitness, it becomes really hard to see the high level picture of „what is tested here“.
As usually, there is a balance to be found.
rullopat 3 hours ago [-]
So if you have a page that is common between, lets say, 30-40 tests, you prefer to copy/paste the new selectors everywhere?
boxed 51 minutes ago [-]
I think the implementation details matter a ton here. I bet you can make this thing work and be useful, but you can also follow this blindly and have just an absolute mess.
I worked at a place where a well meaning QA tech rewrote the test suite to use page objects. It was a total mess and I undid most of that work in the end. It just moved a bunch of xpath expressions a long way from the rest of the test code, and it was all single use anyway.
a_t48 5 hours ago [-]
I'm not really a UI guy, but isn't this MVC (or some subset)?
vasusen 4 hours 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 5 hours ago [-]
Page object is a useful model for writing maintainable tests
oweiler 4 hours ago [-]
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.
In an MVC conception, the UX model becomes a top layer of abstraction of the domain model. It's a natural place to be because for modern apps, users expect "more than forms", i.e.: different ways of cutting up the domain data, presented in different ways, ...
This is something that component-based frontend frameworks struggle with a bit: the hierarchical layout of the DOM doesn't always reflect the interrelations in data between parts of a user experience. Prop drilling is just a reflection of this fact and perhaps it's why we're seeing a rise in the use of state stores. It's not really about state, that's just the technical symptom, it's really about providing a way of defining a (in-browser) data model based on the user experience itself rather than the particularities of the UI substrate.
--
1: https://playwright.dev/docs/pom
This argument also applies to using a function for abstraction.
I've just written a few dozen e2e tests with Playwright. The code looks like:
Each of those lines is 3 to 20 lines of Playwright code. Aggressive DRY is bad, but Page Object Models are usually worth it to reduce duplication and limit churn from UI changes.It was a few years ago, and very AngularJS focused, but I posted something along these lines: https://charemza.name/blog/posts/angularjs/e2e/consider-not-...
In summary: having thing look cleaner at a glance is not helping if you’re (almost) always going to need to do more than glancing
Hadn't considered the Page Object Model and will definitely have to consider how to incorporate that for those who want to do things that way.
---
1: https://github.com/zikani03/basi
As usually, there is a balance to be found.
I worked at a place where a well meaning QA tech rewrote the test suite to use page objects. It was a total mess and I undid most of that work in the end. It just moved a bunch of xpath expressions a long way from the rest of the test code, and it was all single use anyway.
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.