Wait in automated tests<\/strong><\/h2>\n\n\n\nWait is one of the basic and key parts of an automated test. It allows us to perform a delay in the test to, in order to load the web page, or any element on that page, correctly. This will make it possible to check, that the results in a positive or negative completion of the test.<\/p>\n\n\n\n
Wait\u2019s wrong implementation can result in an incorrect test result, e.g. by trying to interact with a page, which has not fully loaded. Another popular problem is lack of an item\u2019s display, because it was waiting, for example, for the server response. However, one of the biggest difficulties connected with the wait\u2019s wrong implementation is the unnecessary waiting, which increases our test duration.<\/p>\n\n\n\n
Wait in Selenium<\/strong><\/h2>\n\n\n\nIn one of the most popular tools for tests automation, that is Selenium, we encounter three types of waits, which I will describe below.<\/p>\n\n\n\n
Implicit wait<\/strong><\/h3>\n\n\n\nIt consists of an attempt to find an element in the DOM for a spcidied time if it is not immediately available. The default value of this wait is 0 and when we change this value, the implicit wait lasts until the end of the session.<\/p>\n\n\n\n![\"Selenium](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/1-1.png\")
<\/a>Fig. 1 Selenium example \u2013 Implicit wait<\/figcaption><\/figure>\n\n\n\nAs presented in the code above, the implementation of this solution is very fast, but it has some limitations. This wait works only with the findElement() method<\/strong>, and that keeps us from waiting to load, for example, the text in the element.<\/p>\n\n\n\nExplicit wait<\/strong><\/h3>\n\n\n\nThanks to it, we have a possibility to stop the test until our expected condition is met. Checking the condition is triggered with a certain frequency until the timeout expires. This means, that when the condition returns a false value, Selenium will wait and try again.<\/p>\n\n\n\n![\"Selenium](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/2-1.png\")
<\/a>Fig. 2 Selenium example \u2013 Explicit wait<\/figcaption><\/figure>\n\n\n\nIn the code presented above, we wait until the title of our page gains the expected value. Keep in mind that the wait is now used only at the time of the trigger<\/strong>, and not as previously \u2013 globally. Here you will find a list of available expected explicit wait conditions for Selenium<\/a>.<\/p>\n\n\n\nFluentWait<\/strong><\/h3>\n\n\n\nWe wait in an explicit manner<\/strong> for a certain situation for a given number of seconds \u2013 for example: the following code for 10 seconds will check if our website has the expected title with the frequency of one second.<\/p>\n\n\n\n![\"Selenium](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/3-1024x42.png\")
Fig. 3 Selenium example \u2013 FluentWait<\/figcaption><\/figure>\n\n\n\nWait in Cypress<\/strong><\/h2>\n\n\n\nCypress, by default, uses dynamic wait for elements or actions available on the web page used in our automated test. We can distinguish the following ways to handle waits.<\/p>\n\n\n\n
Default timeouts<\/strong><\/h3>\n\n\n\nIn Cypress there are 6 default timeouts available. Thanks to the built-in re-try mechanism, they perform checks in a defined by us, or preset time, similarly to the explicit wait previously described:<\/p>\n\n\n\n
\n- defaultCommandTimeout \u2013 it is the time, in which Cypress tries to get to the element or action while executing most of the commands on the DOM.<\/li>\n\n\n\n
- execTimeout – a timeout that defines how long to wait for the system to complete the operations during the cy.exec() command.<\/li>\n\n\n\n
- taskTimeout – the maximum time, in which we wait for a task completion during the cy.task() command.<\/li>\n\n\n\n
- pageLoadTimeout – waits for the “page transition event”. This event occurs when a user visits or leaves a particular web page. This default timeout also waits for the cy.visit(), cy.go(), cy.reload() commands to execute load events. They are triggered when the entire page and all its contents, i.e. style sheet, scripts, iframes and images are loaded.<\/li>\n\n\n\n
- requestTimeout – the maximum time we wait for cy.wait() execution.<\/li>\n\n\n\n
- responseTimeout – waits for the execution of cy.request(), cy.wait(), cy.fixture(), cy.getCookie(), cy.getCookies(), cy.setCookie(), cy.clearCookie(), cy.clearCookies() and cy.screenshot() methods.<\/li>\n<\/ul>\n\n\n\n
If we want to overwrite the values for timeouts, we do it in the cypress.json file:<\/p>\n\n\n\n![\"Cypress](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/4.png\")
<\/a>Fig. 4 Cypress \u2013 cypress.json set value defaultCommandTimeout<\/figcaption><\/figure>\n\n\n\nWe can also change these times for a given action chain or the method itself by sending the object with an expected time:<\/p>\n\n\n\n![\"Cypress](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/5.png\")
<\/a>Fig. 5 Cypress \u2013 implicit subject used and overwriting defaultCommandTimeout by sending object to the get method<\/figcaption><\/figure>\n\n\n\nIn the code above we used implicit subject to create assertion with the .should() method. First, Cypress tries to find the button element within the 20 seconds defined in the object sent {timeout: 20000}, and then performs assertion on that button, to check if it contains the text \u201cSearch in Google\u201d. Here, again, waits up to 20 seconds for the text to appear. We can obtain the timeout while executing the cy.get() and should() method, which will negate the entire test.<\/p>\n\n\n\n
For the get(), find(), cointains() methods, from my experience, I recommend using a timeout on the action chain in case the wait for an item or its properties is extended. Whereas, the timeout set in cypress.json should be limited to a reasonable minimum to avoid unnecessary lengthening of the tests in case we receive a fail.<\/p>\n\n\n\n
In Cypress, we have the possibility to make a similar assertion with an explicit subject by using the .then() method and making an assertion on a JQuery element:<\/p>\n\n\n\n![\"Przyk\u0142ad](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/6.png\")
<\/a>Fig. 6 Cypress example \u2013 assertion with explicit subject<\/figcaption><\/figure>\n\n\n\nIn this case, Cypress first waits up to 20 seconds for the .get() method, and then immediately makes an assertion on the element, omitting the defined defaultCommandTimeout.<\/p>\n\n\n\n
Built-in Wait<\/strong><\/h3>\n\n\n\nCypress has its own implementation of the wait method, which takes up to two arguments:<\/p>\n\n\n\n
\n- One of the first values is a numeric value given in milliseconds. This is the value of time, which elapses between the previous and the next command in the Cypress action chain.<\/li>\n\n\n\n
- The next value we can send in place of time is an alias or an alias table. Aliases are a tremendous construct in Cypress that has many uses and a separate article could be written about it. However, for us, in the waits concept, the most important thing is to focus on the possibility to assign an alias to the API call. We do it through the cy.intercept() and the .as() method, where the as method saves an alias, to which we have access with the use of the @ prefix.<\/li>\n\n\n\n
- The last, optional, value is the option object, which allows us to overwrite the previously defined default times for requestTimeout and responseTimeout. Additionally, it pro {log: true\/false} object.<\/li>\n<\/ul>\n\n\n\n
![\"Cypress](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/7.png\")
<\/a>Fig. 7 Cypress \u2013 ways of cy.wait() implementation<\/figcaption><\/figure>\n\n\n\nThis code shows the Cypress wait implementation. This method allows us to wait in a specific place in the code for a given time or until an appropriate alias appears.<\/p>\n\n\n\n
Creating an alias<\/strong><\/h3>\n\n\n\nIn order to properly create a wait for an alias, we need that alias precisely. One method to create it is to look at the queries made by the browser on our test page. Then, we select the last query or the last few queries made, which, with high probability, will show us that the page is loaded.<\/p>\n\n\n\n![\"The](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/8.png\")
<\/a>Fig. 8 The list of API queries on the www.google.pl page<\/figcaption><\/figure>\n\n\n\nOnce we find the query of interest, all we need to do is use the cy.intercept() method. It allows us to track and manage requests and responses in the network. It allows us to:<\/p>\n\n\n\n
\n- Mock data<\/li>\n\n\n\n
- Validate API requests<\/li>\n\n\n\n
- And thanks to the combination with cy.wait(), wait for the end of the given API query.<\/li>\n<\/ul>\n\n\n\n
Then, with the .as() method, we can save the tracked request as an alias.<\/p>\n\n\n\n
Intercept implementation<\/strong><\/strong><\/p>\n\n\n\n![\"Cypress](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/9.png\")
<\/a>Fig. 9 Cypress example \u2013 implementation of the cy.intercept() method<\/figcaption><\/figure>\n\n\n\nThe intercept implementation, which we subsequently use in the test, is shown above. Its task is to:<\/p>\n\n\n\n
\n- Visit google.pl webpage.<\/li>\n\n\n\n
- Accept cookies.<\/li>\n\n\n\n
- Enter \u201cSii\u201d in the search bar and click on the Enter button.<\/li>\n\n\n\n
- Wait for the @finishedGoogleSearch alias.<\/li>\n\n\n\n
- Check whether the text \u201cOko\u0142o\u201d is visible on the loaded page.<\/li>\n<\/ol>\n\n\n\n
![\"Cypress](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/10.png\")
<\/a>Fig. 10 Cypress example \u2013 test code using the wait for alias method<\/figcaption><\/figure>\n\n\n\nI advise avoiding waits for a given time and focus on waiting for aliases.<\/strong> It will make our tests shorter and the code will be more optimized and significantly free of unexpected exceptions.<\/p>\n\n\n\nOne of the additional packages for the ESLint is the Cypress ESLint Plugin, which allows us to define the rule “cypress\/no-unnecessary-waiting”: “error” and detect these waits while creating automated tests.<\/p>\n\n\n\n
Custom waits implementation<\/strong><\/h3>\n\n\n\nIn case we need a custom wait, that doesn’t qualify for the previously described cy.wait(), we can use a recursive wait with a condition check with every reference.<\/p>\n\n\n\n
Recursion is the reference of a function or definition to itself.<\/strong> It occurs in mathematics (Euclid’s algorithm, Fibonacci sequence), programming and even art (a picture within a picture or placing two mirrors opposite each other – that’s exactly when we get a reflection within a reflection).<\/p>\n\n\n\nBut let’s get back to programming and our example. We want to write a wait, which will wait for the expected item to appear on the page.<\/p>\n\n\n\n![\"Cypress](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/11.png\")
<\/a>Fig. 11 Cypress example \u2013 recursive wait implementation for an element to appear<\/figcaption><\/figure>\n\n\n\nWait performs this task in the following order:<\/p>\n\n\n\n
\n- Retrieving the contents of the body with the .get() method.<\/li>\n\n\n\n
- Then, changing this object into a JQuery object, calling the .find(locator) method on it and finally .length, which returns 0 if the element is not in the body.<\/li>\n\n\n\n
- Waiting in the split time – that is the time after which we want to make another check whether the element meets the given condition.<\/li>\n\n\n\n
- Defining totalTime and starting to increase it by a given break time (split) with each subsequent recursive call.<\/li>\n\n\n\n
- Checking if totalTime is less than or equal to the timeout. Depending on the result of the condition, it recursively calls the checkForElement() function, or calls cy.get(resultText) to negate the test.<\/li>\n\n\n\n
- Finally, calling cy.get(resultsText) when the condition body.find(elementID).length === 0 is not met, which closes the recursion.<\/li>\n<\/ol>\n\n\n\n
It is not a perfect solution of that problem and should be used as a last resort<\/strong>, because we are dealing with a difficulty of code readability and maintainability.<\/p>\n\n\n\nThe code above is very hard to debug in Cypress and incompetent use of recursion or loops may result in falling into an infinite loop. endless loop. There is a possibility of its occurrence when mixing synchronous and asynchronous code or when the increment conditions are incorrectly controlled. Eventually, the infinite loop will cause the test error and the browser will stop responding.<\/p>\n\n\n\n
External wait packages available<\/strong><\/strong><\/h2>\n\n\n\nIn this chapter, I will go over two packages, that I know of, which we can use in our tests.<\/p>\n\n\n\n
\n- cypress-wait-until \u2013 it allows waiting for everything that the cy.wait() method is not waiting for. The cy.waitUntil() method takes two arguments. The first one is a function that executes a Cypress method, methods or a whole chain of actions. The next argument is an option object, which allows controlling the timeout and interval. The code tries to access the browser field for three seconds with a one second interval. By editing the default values, we can freely control the timeout and interval values. The default values for this wait are timeout=5000, interval=200.<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/12.png\")
<\/a>Fig. 12 Cypress \u2013 exemplary implementation of cypress-wait-until<\/figcaption><\/figure>\n\n\n\n\n- cypress-recurse \u2013 the package provides a recursive wait until the expected codition returns a True value. In this case, our expected condition is expect(button).to.have.value(\u2018Szukaj w Google\u2019)}. The method will negate the test if within 30 seconds this condition will not return the True value. The condition itself will be checked with the frequency of 0.5 seconds. Default values for the method are: timeout=4000, limit=15, delay=800.<\/li>\n<\/ul>\n\n\n\n
![\"Cypress](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/01\/13.png\")
<\/a>Fig. 13 Cypress \u2013 exemplary implementation of cypress-recurse<\/figcaption><\/figure>\n\n\n\n![\"job](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/12\/praca-k-EN-4.jpg\")
<\/a><\/figure>\n\n\n\nSelenium vs. Cypress waits<\/strong><\/h2>\n\n\n\nSo let\u2019s look for similarities<\/strong> between Selenium waits and Cypress waits.<\/p>\n\n\n\nLet\u2019s start with the implicit wait. We can observe a similar behavior in Cypress – by controlling “defaultCommandTimeout” or the timeout itself, we can wait for an element to appear on the page with the use of the cy.get() method in the time we specify.<\/p>\n\n\n\n
Explicit wait in Cypress is quite a controversial topic, because it is supposed to check a condition. Cypress .should(‘be.visible’) method can be treated as the equivalent of the expected condition in Selenium elementIsVisible(element).<\/p>\n\n\n\n
However: is the assertion a wait? If we assume that it is, then we can treat all .should() assertions as an explicit wait. I am sure that opinions on this theory are divided, so I leave the answer to this question to your own interpretation \ud83d\ude0a<\/p>\n\n\n\n
Let’s not forget the cy.wait(@alias). It is this wait that can be considered a full-fledged explicit<\/strong>. The presented cypress-wait-until-until and cypress-recurse external packages are closer to an explicit, or even a fluent wait, due to the possibility to control the interval according to which the condition is checked.<\/p>\n\n\n\nSummary<\/strong><\/h2>\n\n\n\nIn this article, I have presented the available ways of waiting for elements in Selenium and Cypress – waits, which allow you to work freely on most elements. I have presented the difference in time with Cypress assertions. I have prepared a sample code with my own wait and have gone over two external packages that we can work with in Cypress, depending on our needs.<\/p>\n\n\n\n
If you are starting your adventure with Cypress, it is worth acquiring knowledge of the cy.wait(‘@Alias’) area from the beginning. It is a basic functionality of the tool, which increases the quality of the code in our automated tests and eliminates the need to wait for the element to load. Good luck!<\/p>\n\n\n\n
Sources<\/h2>\n\n\n\n\n- Selenium \u2013 Documentation<\/a><\/li>\n\n\n\n
- Why Cypress?<\/a><\/li>\n\n\n\n
- GitHub \u2013 Cypress ESLint Plugin<\/a><\/li>\n\n\n\n
- GitHub \u2013 Cypress wait until<\/a><\/li>\n\n\n\n
- GitHub \u2013 Cypress recurse<\/a><\/li>\n<\/ul>\n\n\n\n
***<\/p>\n\n\n\n
If you are interested in the topic of Cypress, Selenium or test automation, we encourage you to check out other articles by our experts<\/a>.<\/p>\n\n\n
In one of the most popular tools for tests automation, that is Selenium, we encounter three types of waits, which I will describe below.<\/p>\n\n\n\n
Implicit wait<\/strong><\/h3>\n\n\n\nIt consists of an attempt to find an element in the DOM for a spcidied time if it is not immediately available. The default value of this wait is 0 and when we change this value, the implicit wait lasts until the end of the session.<\/p>\n\n\n\n<\/a>Fig. 1 Selenium example \u2013 Implicit wait<\/figcaption><\/figure>\n\n\n\nAs presented in the code above, the implementation of this solution is very fast, but it has some limitations. This wait works only with the findElement() method<\/strong>, and that keeps us from waiting to load, for example, the text in the element.<\/p>\n\n\n\nExplicit wait<\/strong><\/h3>\n\n\n\nThanks to it, we have a possibility to stop the test until our expected condition is met. Checking the condition is triggered with a certain frequency until the timeout expires. This means, that when the condition returns a false value, Selenium will wait and try again.<\/p>\n\n\n\n<\/a>Fig. 2 Selenium example \u2013 Explicit wait<\/figcaption><\/figure>\n\n\n\nIn the code presented above, we wait until the title of our page gains the expected value. Keep in mind that the wait is now used only at the time of the trigger<\/strong>, and not as previously \u2013 globally. Here you will find a list of available expected explicit wait conditions for Selenium<\/a>.<\/p>\n\n\n\nFluentWait<\/strong><\/h3>\n\n\n\nWe wait in an explicit manner<\/strong> for a certain situation for a given number of seconds \u2013 for example: the following code for 10 seconds will check if our website has the expected title with the frequency of one second.<\/p>\n\n\n\nFig. 3 Selenium example \u2013 FluentWait<\/figcaption><\/figure>\n\n\n\nWait in Cypress<\/strong><\/h2>\n\n\n\nCypress, by default, uses dynamic wait for elements or actions available on the web page used in our automated test. We can distinguish the following ways to handle waits.<\/p>\n\n\n\n
Default timeouts<\/strong><\/h3>\n\n\n\nIn Cypress there are 6 default timeouts available. Thanks to the built-in re-try mechanism, they perform checks in a defined by us, or preset time, similarly to the explicit wait previously described:<\/p>\n\n\n\n
\n- defaultCommandTimeout \u2013 it is the time, in which Cypress tries to get to the element or action while executing most of the commands on the DOM.<\/li>\n\n\n\n
- execTimeout – a timeout that defines how long to wait for the system to complete the operations during the cy.exec() command.<\/li>\n\n\n\n
- taskTimeout – the maximum time, in which we wait for a task completion during the cy.task() command.<\/li>\n\n\n\n
- pageLoadTimeout – waits for the “page transition event”. This event occurs when a user visits or leaves a particular web page. This default timeout also waits for the cy.visit(), cy.go(), cy.reload() commands to execute load events. They are triggered when the entire page and all its contents, i.e. style sheet, scripts, iframes and images are loaded.<\/li>\n\n\n\n
- requestTimeout – the maximum time we wait for cy.wait() execution.<\/li>\n\n\n\n
- responseTimeout – waits for the execution of cy.request(), cy.wait(), cy.fixture(), cy.getCookie(), cy.getCookies(), cy.setCookie(), cy.clearCookie(), cy.clearCookies() and cy.screenshot() methods.<\/li>\n<\/ul>\n\n\n\n
If we want to overwrite the values for timeouts, we do it in the cypress.json file:<\/p>\n\n\n\n<\/a>Fig. 4 Cypress \u2013 cypress.json set value defaultCommandTimeout<\/figcaption><\/figure>\n\n\n\nWe can also change these times for a given action chain or the method itself by sending the object with an expected time:<\/p>\n\n\n\n<\/a>Fig. 5 Cypress \u2013 implicit subject used and overwriting defaultCommandTimeout by sending object to the get method<\/figcaption><\/figure>\n\n\n\nIn the code above we used implicit subject to create assertion with the .should() method. First, Cypress tries to find the button element within the 20 seconds defined in the object sent {timeout: 20000}, and then performs assertion on that button, to check if it contains the text \u201cSearch in Google\u201d. Here, again, waits up to 20 seconds for the text to appear. We can obtain the timeout while executing the cy.get() and should() method, which will negate the entire test.<\/p>\n\n\n\n
For the get(), find(), cointains() methods, from my experience, I recommend using a timeout on the action chain in case the wait for an item or its properties is extended. Whereas, the timeout set in cypress.json should be limited to a reasonable minimum to avoid unnecessary lengthening of the tests in case we receive a fail.<\/p>\n\n\n\n
In Cypress, we have the possibility to make a similar assertion with an explicit subject by using the .then() method and making an assertion on a JQuery element:<\/p>\n\n\n\n<\/a>Fig. 6 Cypress example \u2013 assertion with explicit subject<\/figcaption><\/figure>\n\n\n\nIn this case, Cypress first waits up to 20 seconds for the .get() method, and then immediately makes an assertion on the element, omitting the defined defaultCommandTimeout.<\/p>\n\n\n\n
Built-in Wait<\/strong><\/h3>\n\n\n\nCypress has its own implementation of the wait method, which takes up to two arguments:<\/p>\n\n\n\n
\n- One of the first values is a numeric value given in milliseconds. This is the value of time, which elapses between the previous and the next command in the Cypress action chain.<\/li>\n\n\n\n
- The next value we can send in place of time is an alias or an alias table. Aliases are a tremendous construct in Cypress that has many uses and a separate article could be written about it. However, for us, in the waits concept, the most important thing is to focus on the possibility to assign an alias to the API call. We do it through the cy.intercept() and the .as() method, where the as method saves an alias, to which we have access with the use of the @ prefix.<\/li>\n\n\n\n
- The last, optional, value is the option object, which allows us to overwrite the previously defined default times for requestTimeout and responseTimeout. Additionally, it pro {log: true\/false} object.<\/li>\n<\/ul>\n\n\n\n
<\/a>Fig. 7 Cypress \u2013 ways of cy.wait() implementation<\/figcaption><\/figure>\n\n\n\nThis code shows the Cypress wait implementation. This method allows us to wait in a specific place in the code for a given time or until an appropriate alias appears.<\/p>\n\n\n\n
Creating an alias<\/strong><\/h3>\n\n\n\nIn order to properly create a wait for an alias, we need that alias precisely. One method to create it is to look at the queries made by the browser on our test page. Then, we select the last query or the last few queries made, which, with high probability, will show us that the page is loaded.<\/p>\n\n\n\n<\/a>Fig. 8 The list of API queries on the www.google.pl page<\/figcaption><\/figure>\n\n\n\nOnce we find the query of interest, all we need to do is use the cy.intercept() method. It allows us to track and manage requests and responses in the network. It allows us to:<\/p>\n\n\n\n
\n- Mock data<\/li>\n\n\n\n
- Validate API requests<\/li>\n\n\n\n
- And thanks to the combination with cy.wait(), wait for the end of the given API query.<\/li>\n<\/ul>\n\n\n\n
Then, with the .as() method, we can save the tracked request as an alias.<\/p>\n\n\n\n
Intercept implementation<\/strong><\/strong><\/p>\n\n\n\n<\/a>Fig. 9 Cypress example \u2013 implementation of the cy.intercept() method<\/figcaption><\/figure>\n\n\n\nThe intercept implementation, which we subsequently use in the test, is shown above. Its task is to:<\/p>\n\n\n\n
\n- Visit google.pl webpage.<\/li>\n\n\n\n
- Accept cookies.<\/li>\n\n\n\n
- Enter \u201cSii\u201d in the search bar and click on the Enter button.<\/li>\n\n\n\n
- Wait for the @finishedGoogleSearch alias.<\/li>\n\n\n\n
- Check whether the text \u201cOko\u0142o\u201d is visible on the loaded page.<\/li>\n<\/ol>\n\n\n\n
<\/a>Fig. 10 Cypress example \u2013 test code using the wait for alias method<\/figcaption><\/figure>\n\n\n\nI advise avoiding waits for a given time and focus on waiting for aliases.<\/strong> It will make our tests shorter and the code will be more optimized and significantly free of unexpected exceptions.<\/p>\n\n\n\nOne of the additional packages for the ESLint is the Cypress ESLint Plugin, which allows us to define the rule “cypress\/no-unnecessary-waiting”: “error” and detect these waits while creating automated tests.<\/p>\n\n\n\n
Custom waits implementation<\/strong><\/h3>\n\n\n\nIn case we need a custom wait, that doesn’t qualify for the previously described cy.wait(), we can use a recursive wait with a condition check with every reference.<\/p>\n\n\n\n
Recursion is the reference of a function or definition to itself.<\/strong> It occurs in mathematics (Euclid’s algorithm, Fibonacci sequence), programming and even art (a picture within a picture or placing two mirrors opposite each other – that’s exactly when we get a reflection within a reflection).<\/p>\n\n\n\nBut let’s get back to programming and our example. We want to write a wait, which will wait for the expected item to appear on the page.<\/p>\n\n\n\n<\/a>Fig. 11 Cypress example \u2013 recursive wait implementation for an element to appear<\/figcaption><\/figure>\n\n\n\nWait performs this task in the following order:<\/p>\n\n\n\n
\n- Retrieving the contents of the body with the .get() method.<\/li>\n\n\n\n
- Then, changing this object into a JQuery object, calling the .find(locator) method on it and finally .length, which returns 0 if the element is not in the body.<\/li>\n\n\n\n
- Waiting in the split time – that is the time after which we want to make another check whether the element meets the given condition.<\/li>\n\n\n\n
- Defining totalTime and starting to increase it by a given break time (split) with each subsequent recursive call.<\/li>\n\n\n\n
- Checking if totalTime is less than or equal to the timeout. Depending on the result of the condition, it recursively calls the checkForElement() function, or calls cy.get(resultText) to negate the test.<\/li>\n\n\n\n
- Finally, calling cy.get(resultsText) when the condition body.find(elementID).length === 0 is not met, which closes the recursion.<\/li>\n<\/ol>\n\n\n\n
It is not a perfect solution of that problem and should be used as a last resort<\/strong>, because we are dealing with a difficulty of code readability and maintainability.<\/p>\n\n\n\nThe code above is very hard to debug in Cypress and incompetent use of recursion or loops may result in falling into an infinite loop. endless loop. There is a possibility of its occurrence when mixing synchronous and asynchronous code or when the increment conditions are incorrectly controlled. Eventually, the infinite loop will cause the test error and the browser will stop responding.<\/p>\n\n\n\n
External wait packages available<\/strong><\/strong><\/h2>\n\n\n\nIn this chapter, I will go over two packages, that I know of, which we can use in our tests.<\/p>\n\n\n\n
\n- cypress-wait-until \u2013 it allows waiting for everything that the cy.wait() method is not waiting for. The cy.waitUntil() method takes two arguments. The first one is a function that executes a Cypress method, methods or a whole chain of actions. The next argument is an option object, which allows controlling the timeout and interval. The code tries to access the browser field for three seconds with a one second interval. By editing the default values, we can freely control the timeout and interval values. The default values for this wait are timeout=5000, interval=200.<\/li>\n<\/ul>\n\n\n\n
<\/a>Fig. 12 Cypress \u2013 exemplary implementation of cypress-wait-until<\/figcaption><\/figure>\n\n\n\n\n- cypress-recurse \u2013 the package provides a recursive wait until the expected codition returns a True value. In this case, our expected condition is expect(button).to.have.value(\u2018Szukaj w Google\u2019)}. The method will negate the test if within 30 seconds this condition will not return the True value. The condition itself will be checked with the frequency of 0.5 seconds. Default values for the method are: timeout=4000, limit=15, delay=800.<\/li>\n<\/ul>\n\n\n\n
<\/a>Fig. 13 Cypress \u2013 exemplary implementation of cypress-recurse<\/figcaption><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\nSelenium vs. Cypress waits<\/strong><\/h2>\n\n\n\nSo let\u2019s look for similarities<\/strong> between Selenium waits and Cypress waits.<\/p>\n\n\n\nLet\u2019s start with the implicit wait. We can observe a similar behavior in Cypress – by controlling “defaultCommandTimeout” or the timeout itself, we can wait for an element to appear on the page with the use of the cy.get() method in the time we specify.<\/p>\n\n\n\n
Explicit wait in Cypress is quite a controversial topic, because it is supposed to check a condition. Cypress .should(‘be.visible’) method can be treated as the equivalent of the expected condition in Selenium elementIsVisible(element).<\/p>\n\n\n\n
However: is the assertion a wait? If we assume that it is, then we can treat all .should() assertions as an explicit wait. I am sure that opinions on this theory are divided, so I leave the answer to this question to your own interpretation \ud83d\ude0a<\/p>\n\n\n\n
Let’s not forget the cy.wait(@alias). It is this wait that can be considered a full-fledged explicit<\/strong>. The presented cypress-wait-until-until and cypress-recurse external packages are closer to an explicit, or even a fluent wait, due to the possibility to control the interval according to which the condition is checked.<\/p>\n\n\n\nSummary<\/strong><\/h2>\n\n\n\nIn this article, I have presented the available ways of waiting for elements in Selenium and Cypress – waits, which allow you to work freely on most elements. I have presented the difference in time with Cypress assertions. I have prepared a sample code with my own wait and have gone over two external packages that we can work with in Cypress, depending on our needs.<\/p>\n\n\n\n
If you are starting your adventure with Cypress, it is worth acquiring knowledge of the cy.wait(‘@Alias’) area from the beginning. It is a basic functionality of the tool, which increases the quality of the code in our automated tests and eliminates the need to wait for the element to load. Good luck!<\/p>\n\n\n\n
Sources<\/h2>\n\n\n\n\n- Selenium \u2013 Documentation<\/a><\/li>\n\n\n\n
- Why Cypress?<\/a><\/li>\n\n\n\n
- GitHub \u2013 Cypress ESLint Plugin<\/a><\/li>\n\n\n\n
- GitHub \u2013 Cypress wait until<\/a><\/li>\n\n\n\n
- GitHub \u2013 Cypress recurse<\/a><\/li>\n<\/ul>\n\n\n\n
***<\/p>\n\n\n\n
If you are interested in the topic of Cypress, Selenium or test automation, we encourage you to check out other articles by our experts<\/a>.<\/p>\n\n\n
<\/a>As presented in the code above, the implementation of this solution is very fast, but it has some limitations. This wait works only with the findElement() method<\/strong>, and that keeps us from waiting to load, for example, the text in the element.<\/p>\n\n\n\n Thanks to it, we have a possibility to stop the test until our expected condition is met. Checking the condition is triggered with a certain frequency until the timeout expires. This means, that when the condition returns a false value, Selenium will wait and try again.<\/p>\n\n\n\n In the code presented above, we wait until the title of our page gains the expected value. Keep in mind that the wait is now used only at the time of the trigger<\/strong>, and not as previously \u2013 globally. Here you will find a list of available expected explicit wait conditions for Selenium<\/a>.<\/p>\n\n\n\n We wait in an explicit manner<\/strong> for a certain situation for a given number of seconds \u2013 for example: the following code for 10 seconds will check if our website has the expected title with the frequency of one second.<\/p>\n\n\n\n Cypress, by default, uses dynamic wait for elements or actions available on the web page used in our automated test. We can distinguish the following ways to handle waits.<\/p>\n\n\n\n In Cypress there are 6 default timeouts available. Thanks to the built-in re-try mechanism, they perform checks in a defined by us, or preset time, similarly to the explicit wait previously described:<\/p>\n\n\n\n If we want to overwrite the values for timeouts, we do it in the cypress.json file:<\/p>\n\n\n\n We can also change these times for a given action chain or the method itself by sending the object with an expected time:<\/p>\n\n\n\n In the code above we used implicit subject to create assertion with the .should() method. First, Cypress tries to find the button element within the 20 seconds defined in the object sent {timeout: 20000}, and then performs assertion on that button, to check if it contains the text \u201cSearch in Google\u201d. Here, again, waits up to 20 seconds for the text to appear. We can obtain the timeout while executing the cy.get() and should() method, which will negate the entire test.<\/p>\n\n\n\n For the get(), find(), cointains() methods, from my experience, I recommend using a timeout on the action chain in case the wait for an item or its properties is extended. Whereas, the timeout set in cypress.json should be limited to a reasonable minimum to avoid unnecessary lengthening of the tests in case we receive a fail.<\/p>\n\n\n\n In Cypress, we have the possibility to make a similar assertion with an explicit subject by using the .then() method and making an assertion on a JQuery element:<\/p>\n\n\n\n In this case, Cypress first waits up to 20 seconds for the .get() method, and then immediately makes an assertion on the element, omitting the defined defaultCommandTimeout.<\/p>\n\n\n\n Cypress has its own implementation of the wait method, which takes up to two arguments:<\/p>\n\n\n\n This code shows the Cypress wait implementation. This method allows us to wait in a specific place in the code for a given time or until an appropriate alias appears.<\/p>\n\n\n\n In order to properly create a wait for an alias, we need that alias precisely. One method to create it is to look at the queries made by the browser on our test page. Then, we select the last query or the last few queries made, which, with high probability, will show us that the page is loaded.<\/p>\n\n\n\n Once we find the query of interest, all we need to do is use the cy.intercept() method. It allows us to track and manage requests and responses in the network. It allows us to:<\/p>\n\n\n\n Then, with the .as() method, we can save the tracked request as an alias.<\/p>\n\n\n\n Intercept implementation<\/strong><\/strong><\/p>\n\n\n\n The intercept implementation, which we subsequently use in the test, is shown above. Its task is to:<\/p>\n\n\n\n I advise avoiding waits for a given time and focus on waiting for aliases.<\/strong> It will make our tests shorter and the code will be more optimized and significantly free of unexpected exceptions.<\/p>\n\n\n\n One of the additional packages for the ESLint is the Cypress ESLint Plugin, which allows us to define the rule “cypress\/no-unnecessary-waiting”: “error” and detect these waits while creating automated tests.<\/p>\n\n\n\n In case we need a custom wait, that doesn’t qualify for the previously described cy.wait(), we can use a recursive wait with a condition check with every reference.<\/p>\n\n\n\n Recursion is the reference of a function or definition to itself.<\/strong> It occurs in mathematics (Euclid’s algorithm, Fibonacci sequence), programming and even art (a picture within a picture or placing two mirrors opposite each other – that’s exactly when we get a reflection within a reflection).<\/p>\n\n\n\n But let’s get back to programming and our example. We want to write a wait, which will wait for the expected item to appear on the page.<\/p>\n\n\n\n Wait performs this task in the following order:<\/p>\n\n\n\n It is not a perfect solution of that problem and should be used as a last resort<\/strong>, because we are dealing with a difficulty of code readability and maintainability.<\/p>\n\n\n\n The code above is very hard to debug in Cypress and incompetent use of recursion or loops may result in falling into an infinite loop. endless loop. There is a possibility of its occurrence when mixing synchronous and asynchronous code or when the increment conditions are incorrectly controlled. Eventually, the infinite loop will cause the test error and the browser will stop responding.<\/p>\n\n\n\n In this chapter, I will go over two packages, that I know of, which we can use in our tests.<\/p>\n\n\n\n So let\u2019s look for similarities<\/strong> between Selenium waits and Cypress waits.<\/p>\n\n\n\n Let\u2019s start with the implicit wait. We can observe a similar behavior in Cypress – by controlling “defaultCommandTimeout” or the timeout itself, we can wait for an element to appear on the page with the use of the cy.get() method in the time we specify.<\/p>\n\n\n\n Explicit wait in Cypress is quite a controversial topic, because it is supposed to check a condition. Cypress .should(‘be.visible’) method can be treated as the equivalent of the expected condition in Selenium elementIsVisible(element).<\/p>\n\n\n\n However: is the assertion a wait? If we assume that it is, then we can treat all .should() assertions as an explicit wait. I am sure that opinions on this theory are divided, so I leave the answer to this question to your own interpretation \ud83d\ude0a<\/p>\n\n\n\n Let’s not forget the cy.wait(@alias). It is this wait that can be considered a full-fledged explicit<\/strong>. The presented cypress-wait-until-until and cypress-recurse external packages are closer to an explicit, or even a fluent wait, due to the possibility to control the interval according to which the condition is checked.<\/p>\n\n\n\n In this article, I have presented the available ways of waiting for elements in Selenium and Cypress – waits, which allow you to work freely on most elements. I have presented the difference in time with Cypress assertions. I have prepared a sample code with my own wait and have gone over two external packages that we can work with in Cypress, depending on our needs.<\/p>\n\n\n\n If you are starting your adventure with Cypress, it is worth acquiring knowledge of the cy.wait(‘@Alias’) area from the beginning. It is a basic functionality of the tool, which increases the quality of the code in our automated tests and eliminates the need to wait for the element to load. Good luck!<\/p>\n\n\n\n ***<\/p>\n\n\n\n If you are interested in the topic of Cypress, Selenium or test automation, we encourage you to check out other articles by our experts<\/a>.<\/p>\n\n\nExplicit wait<\/strong><\/h3>\n\n\n\n
<\/a>FluentWait<\/strong><\/h3>\n\n\n\n
Wait in Cypress<\/strong><\/h2>\n\n\n\n
Default timeouts<\/strong><\/h3>\n\n\n\n
\n
<\/a><\/a><\/a>Built-in Wait<\/strong><\/h3>\n\n\n\n
\n
<\/a>Creating an alias<\/strong><\/h3>\n\n\n\n
<\/a>\n
<\/a>\n
<\/a>Custom waits implementation<\/strong><\/h3>\n\n\n\n
<\/a>\n
External wait packages available<\/strong><\/strong><\/h2>\n\n\n\n
\n
<\/a>\n
<\/a><\/a><\/figure>\n\n\n\nSelenium vs. Cypress waits<\/strong><\/h2>\n\n\n\n
Summary<\/strong><\/h2>\n\n\n\n
Sources<\/h2>\n\n\n\n
\n