Why nowadays do I consider Page-Objects an anti-pattern in web test automation?

Add testability on day one, and get rid of unnecessary complexities

First, let me give you my perspective on the Page-Objects testing automation pattern in a few words.

An abstraction layer of the application under test's pages where we define the elements we want to interact with and the methods to interact with them.
~ Walmyr F.

Now to the point.

In the past, it was common to build the state in the application under test (AUT) via its graphical user interface (GUI). So, it made sense to use Page-Objects, to reduce code duplications and, as a bonus, having readable tests.

However, web technologies have evolved, and we can take advantage of all they offer.

Modern frontend applications are built tightly decoupled from backend systems, and they're componentized.

This means that we can build the state of the AUT in many different programmatic ways, resulting in tests that require a specific state, not having to rely on lots of GUI elements other than the ones' target of the test.

Some mechanisms for state creation are:

• Calling an API via a network request
• Using the browser's API to interact with the window object, localStorage, sessionStorage, etc.
• Mocking requests with static files
• Testing components in isolation
• Setting cookies

All that results in simpler tests without unnecessary abstractions (Page-Objects) that might not be useful if we build apps with testability in mind.

The web has evolved. Finally, testing has too!

Yup, that's Cypress.io's slogan, and if I were you, I would give it a try, as it allows you to write readable and simple tests.

By the way, I've a few Cypress courses on Udemy. Check them out!

Thanks for reading. 😉