Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
I am new for writing e2e UI test using cypress. But I am uncertain if it's good practice to use page object model, when I repeatedly need to use same elements in different test cases. Does "Aap Action" Cypress we could considered for writing E2E test or for component test?
In cypress best practices it says to not use page object, what is meant by test specs in isolation.
In Cypress, it is not recommended to use the traditional Page Object Model (POM) approach for end-to-end UI testing. Instead, recommended approach is to use Cypress custom commands or "Aap Action" as you have mentioned, which allows for a more fluent and expressive syntax for writing tests.
In Cypress, custom commands are used to abstract away implementation details of your application's DOM and provide a more expressive API for interacting with it. This approach allows for a more readable and maintainable test code base.
Regarding the repeated usage of same elements in different test cases, Cypress offers the concept of "Fixtures" and "Custom Commands" that can be used to define data or reusable test steps respectively, which can be used across different tests.
As for the concept of "test specs in isolation", it means that each test case should be independent and not dependent on the state of other tests. Each test case should set up its own preconditions and assertions, and not rely on the outcome of other test cases. This allows for easier debugging, maintenance, and better test coverage.
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 div/div/h1/select
With POM we are more likely to have a lookup for, say, select_country which is defined in a POM definition file
select_country: 'div/div/h1/select'
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
form#user-signup/select#country
which achieves all three things:
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
form/select
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
