Suppose we have a problem to cover the functionality of certain website with automation tests. For instance we can consider the website https://www.saucedemo.com/v1/index.html without loss of generality. The website is devoted to illustrating of different test cases that occur during unsuccessful login process. It contains the form with username and password fields to get the access to the next page, and in case of unsuccessful log in, the error message with corresponding text is shown. This website is convenient to be used as a model example for all typical flows of users behaviour that could be covered by tests with a minimum amount of effort.
Successful login without any doubt as a positive test case means inputting correct username and password. Negative tests occur when a user is left on the same page and an appropriate error message is shown. It can happen when a user enters an empty or wrong username or password. Different tests can be considered to cover those cases. However, taking into account that most of developed tests are quite similar and optimising the cases authors demonstrate only valuable and significant of them in this article. More test cases can be found in the project repository at https://github.com/InaKrasnokutska/CypressPOM. To run the solution you just need to pull and run npm i to setup dependencies, and later npm run cy:open to see how it works.
Cypress is chosen to demonstrate how to create tests in different manners. All pros and cons of each approach are analysed and highlighted. There is a lack of good resources on the Internet about usage of the Page Object design pattern in Cypress Cypress [1], and each resource shows only one point of view and it is hard to understand the correlation between them.
All possible variations of implementing Page Object Model (POM) are constructed in this article. It happens when a locked out user enters his/her username and password and receives an appropriate error message. Other test cases can be found at https://github.com/InaKrasnokutska/CypressPOM. In the next subsections we will discuss 9 approaches to organise selected test case. For convenience and quick search of files with tests (specs) in the repository they have names according to subsection numbers in this article where they are discussed.
Before diving into the Page Object design pattern, let us create a Cypress test without it.
According to this decision the code appears very strict forward because in the spec file we need to prescribe the interaction with each DOM element of the page. This interaction is done with the help of the function cy.get() that locates an element with the corresponding selector of the element passed into it as the parameter.
Next we emulate the user's action by typing username and password and clicking the button (.type() and .click() functions). At the end of the scenario we validate the error message using .should() function for assertion. This approach lets us to obtain expected result of testing but in the same time it does not fit list of quality criteria [2] because of • complexity of maintenance and updating, • level of duplication increase dependent on covered scenarios growth, • violation of principles: KISS, DRY, SOLID etc.
For improving the code above let us use the Page Object design pattern and update the code according to style used in Selenium/Java [3].
First of all, we describe the class that contains selectors of elements in variables. Then, implementing functions and locators we use selectors predefined in variables. Here locators are implemented with cy.get() help and are used to perform actions on page. Considering pros and cons of this approach, we can say that it isolates the logics of selecting elements apart from processing scenarios. This isolation improves disadvantages illuminated in the previous approach. At the same time this approach has disadvantage because assertions are performed by class methods, and it is better to leave assertions in the spec file.
Thus, the next step of optimization is extension of class functionality for providing a possibility to make assertions within the spec file.
With this aim, let us define a function in class that will give access to the element, a kind of getter for error messages.
Listing 4: File login_2. As a result of optimisation we obtained improvement of code. However, at the same time, the code is still not uniformed, as one element on the page has accessor function, and others do not have. Code can be understood better when we suppose that the necessity to call those elements directly in a spec file exists. For instance, when we need to verify that in case of unsuccessful username input the element changes its style (red color etc.).
Let us eliminate the shortcomings of the previous version and define functions for access to each page element. Evaluating the code, we observe that it currently seems overloaded with functions. That happens because we keep separately selectors of each element and create distinct functions to access each element that with help of selectors return us the locators of elements.
One of the methods to simplify and optimise the code is the union of selectors and locators. It can be done because out of class only wrapped elements are used to perform actions on them. That is why there is no sense to keep distinct properties only for selectors.
Let us delete from the previous variant all the variables for selectors and strictly pass selectors as arguments in cy.get(). Each locator is obtained as a method that returns the element. As a consequence the tests in spec_2.3.1.cy.js look the same as ones in spec_2.2.2.cy.js and work as well.
Another way to define methods is the usage of anonymous functions. Function expressions are not hoisted, which means it is created only when the execution flow reaches it and can be used from that moment onwards.
Listing 8: Part of file login_2.3.2.page.js g e t U s e r n a m e I n p u t = f u n c t i o n ( ) { return cy . g e t ( ' # u s e r −name ' ) ; } g e t P a s s w o r d I n p u t = f u n c t i o n ( ) { return cy . g e t ( ' # p a s s w o r d ' ) ; } g e t L o g i n B u t t o n = f u n c t i o n ( ) { return cy . g e t ( ' # l o g i n − b u t t o n ' ) ; } g e t E r r o r M e s s a g e = f u n c t i o n ( ) { return cy . g e t ( ' [ d a t a − t e s t = " e r r o r " ] ' ) ; }
The same as in the previous case, tests do not have changes (tests in spec_2.2.3.cy.js are the same as in spec_2.2.2.cy.js).
The usage of previous approach does not make semantic separation between different parts of the Page Object file, that is why we can perform aggregation and place locators into the elements object thereby dividing the functions into two groups: functions devoted to access elements and functions devoted to actions.
Let us use getters names as the keys and locators functions as the values in elements. According to this approach we refer firstly to the elements object and then to corresponding function every time we need to refer to the locators functions in code of action functions. Similar style we need to keep in the spec code also. This approach can be found on some legacy projects or on projects not supporting modern stack.
Analyzing a block of elements we can note that it contains a long construction function() { return . . . } and the idea to shorten or optimize it appears. It can be done if the project uses standard JavaScript EcmaScript 6 or higher. Then, using arrow functions syntax we can obtain a more concise look of code. Investigating available articles on this topic we found out that most of the resources on the Internet recommend writing code with POM as it is shown in this subsection. However, in most cases they use incorrect names for functions in the elements object. The emphasis is on the subject and not on performing an action over the subject (verbs get, take etc. are omitted), for instance usernameInput(), loginButton(). When we need to refer to the part of elements in the tests definitely we want to name the elements as a noun, but round brackets for function call cannot be omitted. In that way code looks incomprehensible and weird violating name convention (loginPage.elements.errorMessage().should('be.visible')).
On the one hand this kind of names has benefits because they are used to denote locators of elements. But on the other hand it has the drawback: this part of code is performing some action and first of all it is a function and it should respect the name conventions for functions.
This article shows eight approaches how to construct Cypress tests using POM. The connections between them are stressed as their evolution while writing code developing E2E tests. Project using approaches highlighted in first subsections still can be found on the Internet while studying how to write tests with Cypress JS. The authors highlight advantages and disadvantages of the approaches and offer the solution of problems. This article can be used both as a combined overview of different approaches and as a manual for those who are struggling to write tests with Cypress in a better way. For further investigation other patterns and solutions like Cypress commands, aliases, application actions, could be discovered.
The drawback described above can be avoided by using assessor properties. They are property getters, new types of properties (along with the regular data properties). They are essentially functions that execute on getting value, but look like regular properties to an external code. "getter" methods are accessor properties . In an object literal they are denoted by get. Descriptor for accessor properties has get -a function without arguments, that works when a property is read. The getter works when errorMessage is read in spec. From the outside, an accessor property looks like a regular one. That's the idea of accessor properties. We don't call errorMessage as a function, we read it normally: the getter runs behind the scenes.
A minor drawback of this approach is that sometimes it is necessary to pass a parameter to the locator functions (for example referring to the i-th row of the table), then we need to combine the use of ordinary functions and assessor properties.