| > In my experience, Page Objects sound neat in theory but end up as a leaky abstraction: they mix UI details with test logic, duplicate flows, You might be asking too much of them to the point they become a burden. 1. Page Object Model should not contain any test-related stuff. It should abstract common page interactions: registerUser({ email: string, password: string, displayName: string })
findProduct(name: string)
addProductToCart(id: string, quantity: number)
etcThen what you do in your tests is: registerUser("abc@foo.net", "passw0rd", "foo name")
login("abc@foo.net", "passw0rd")'
// now you test
expect(page).findByText("Welcome back foo name").toBeVisible()
> and make even trivial UI changes ripple through dozens of files.2. Given my previous example, if you changed the login or registration form you'd only update the implementation of `registerUser`. In any case I also want to emphasize: POMs are very useful when collecting and reusing the data (e.g. in the previous example `login()` would take no params and reuse those declared before), you can achieve 95% of their functionality with plain simple helper functions. |