Best Practices - Using Waits in Leapwork

When performing automation testing for an application, then the test automation tool and Application Under Test(AUT) shall work concurrently and parallel to each other i.e. in a synchronized way.

If these two components do not work in a concurrent manner i.e. if the test automation tool is faster than the application which takes time to load certain elements, then it causes the synchronization issue due to which the user may encounter “ElementNotVisibleException” or “NoSuchElementException” exceptions. So in order to avoid synchronization issues, waits are used.

In Leapwork, we use different waits to handle the synchronization issues which are usually seen for the applications involving javascript and AJAX calls. These waits are:

Timeout(sec)

The first type of wait is the Timeout property of the Web building blocks which is a dynamic wait i.e. if the action is completed prior to 10 seconds, the "success" connector will execute. This timeout frame is in seconds and it can be used in scenarios where suppose you are opening a URL of the web page which takes 20 seconds to settle in the browser. If you have provided timeout seconds less than 20 seconds than, while the execution of the block, the user will face a Timeout exception in the test run log.

This wait is an intelligent wait as it tries to move the execution to the next block as soon as the element is found and does not wait for whole the timeout seconds frame to elapse.

By default value of this timeout is 10 seconds.

Await DOM Change:

This is a property of the web building blocks which is used when the user wants that the DOM of a page shall be settled first before performing the operation that is been intended in that building block of Leapwork.

This action will ensure that the requested action, for example, Click Web Element, is not "rushing ahead", but waits for the web page to "settle". The default timing value here is 3 seconds, and it is recommended to be extended based on the type of web application.

Await Not Found:

This property, when checked, the building block will assume that the web element is currently present and will wait until it can no longer be found on the page before proceeding.

This can be useful for instance when waiting for a “Loading…” message to disappear.

Await Requests:

This property of the web building blocks delay the search for the web element until there have been no active XHR requests for a specific period of time — for instance, 3 seconds.

This is useful when waiting for behind-the-scenes updates with XHR to occur. Some enterprise web applications use XHR and DOM changes extensively behind the scenes, even switching out existing button tags with new ones. This includes Microsoft Dynamics 365 and Salesforce.

For any clarification, please contact our Priority Support.