When performing automation testing for an application, then 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 does 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 user may encounter “ElementNotVisibleException” or “NoSuchElementException” exceptions. So in order to avoid the synchronization issues, waits are used.
First type of wait is 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 scenario 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, user will face 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 do 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 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 extend based on the type of web application.
This is a kind of wait which is used in the LEAPWORK when user wants to stop the execution for a specific period of time. User can use Wait building block to use this static wait. By default, wait building blocks have delay time of 3 seconds but it shall be increased based on the type and complexity of the application.
Note: This wait is advisable to be used only in that scenario when the dynamic wait and Await DOM Change does not help to resolve the synchronization issues.
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.
This property of the web building blocks delay the search for the web element until there has 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.