It is often better to avoid the abstraction of page objects because doing so will encourage the development of automation that does not reply on visible user elements that are accessible to actual humans. btw I have used the POM model in several organizations (they were all with selenium).
With Cypress I have followed the model of scoping down to the desired element by using HTML structure and visible elements. When used carefully they will allow you to actually describe the element in human readable English without using the POM abstraction model
A couple of example will help:
Without POM we might have some unfriendly locator code such as
With POM we are more likely to have a lookup for, say,
select_country which is defined in a POM definition file
The abstraction of a POM model can be a great improvement as the test code is much more readable as to what it is targeting. However there is now a new problem - we have an additional abstraction layer to maintain which means dealing with naming, orphans and duplicates. More significantly we are relying on hidden code not visible to the user and we are not ensuring that attributes that should work - such as the label for an input field - do work, so our POM automation code is not the same as an actual user who would not be using those DIV elements in their browser usage but would rely on the label text to identify the input field it applies to.
So the target locator to use here might be something like
which achieves all three things:
- it says, in English, that there is a user signup form and it has an input for country (specification)
- it uniquely identifies the field for automation code, as well as css and js (testability)
- it relies on the actual presence of a form that has an input field visible to the user (accessibility)
If there is only one form and only one dropdown you can avoid the use of the ID's (which are invisible to the user after all) and you could then have
However the drawback with this approach is that the test no longer describes what the dropdown is for in english and no longer follows the principle that implementations should have specifications (unit tests). This is what the POM model addresses in its naming abstractions.
Long story short, using locators with the right attributes is the way to test both functionality and accessibility while supporting maintainability. This is actually true of both Cypress and Selenium