What is WAIT really about?

WebDriver provides us many ways to wait for an element to show, like implicitWait, FluentWait etc. But wait! why do we have to wait?

Do we need to wait if we are testing against a static web page?
A static web page is delivered to the user exactly as stored and it displays the same information for all users, from all contexts. Once the page is fully loaded(AKA driver.get(URL) is executed), all elements are going to be there forever till you navigate to some other page.

So no, we don’t have to wait if everything is static.

It is the DYNAMIC elements that keep us waiting
Very rare a modern web application is not dynamic. Nowadays through server-side scripting and client-side javascript and ajax, a web can change a page’s content in response to different contexts or conditions, or in response to mouse or keyboard actions or at specified timing events:

  • it can ‘remember’ its user’s preference and serve different content to different users.
  • it can display dynamic content like: Animation, video, slides, popups, fly-in/out, fade-in/out etc.
  • it can interact with its user on the fly in the form of dialog, widget box,
  • it can update section of page silently to serve user better

This dynamism is users’ meat, but us automation engineers’ poison! Not handling this dynamism properly, then our script will never run stably!

Everything time when we try to interact with a web element, we have to make sure that the element is indeed there for interaction, we thus have to be patient and wait if they are still on their way to the page!

So, to truly understand WAIT, we need to understand the dynamism of the web.

How dynamism is achieved?
Put it in the most simplistic way: Through server-side scripting, like Java, PHP, Perl, .NET, JSP, node.js and other languages; and client-side scripting like javaScript and Ajax(although server-side scripts/servlets are needed to give the response). And often server-side works together with client side.

In server-side scripting, parameters determine how the assembly of every new web page proceeds, including the setting up of more client-side processing. Server responses may be determined by such conditions as data in a posted HTML form, parameters in the URL, the type of browser being used, the passage of time, or a database or server state. Via server-side scripting we can change the supplied page source between pages, adjusting the sequence or reload of the web pages or web content supplied to the browser.

Client-side Scripting processes the web page using HTML scripting running in the browser as it loads. JavaScript and other scripting languages determine the way the HTML in the received page is parsed into the Document Object Model(DOM), that represents the loaded web page. Using this technology we can dynamically update or change the DOM. Most sound, animations, changing text etc. we see are done via client-side scripting.

The major client-side scripting languages are javaScript, a language to manipulate local web elements on the fly; and AJAX, a remote scripting technique by which the DHTML page requests additional information from a server, using a hidden Frame, XMLHttpRequests, or a web service.

JavaScript and Ajax are the major players to contributors to make web UI dynamic, and they are ubiquitous in modern web, thus it is essential for us automation engineers to understand javascript and Ajax.

Besides javascript and ajax, we also need to understand how browser works in order to understand a web element’s whereabout.

How automation addresses dynamism of web
Handling dynamism properly is essential to make automation stable and effective. To handle it right we need to understand:

  • what triggers the dynamic behavior: is it user action? is it timing, or something else?
  • How to check the status of page loading, ajax call status, element whereabouts.
  • Wise wait strategy

Leave a Reply

Your email address will not be published. Required fields are marked *