How do we know that the web page we are interested in has loaded and is ready for us to start running our scripts against? It sounds like a simple question; however, it is one of the things that always poses great problems to automation engineers. If you are ever asked why a script doesn’t work when the code seems sensible, your usual reply should probably be, It’s a waiting trap!

Waiting traps are probably the most common problems in Selenium WebDriver scripts; appallingly, most of the time, automation engineers don’t even realize they have them. AJAX and JavaScript-heavy sites are especially prone to waiting traps, but you can run into them with sites that don’t use much AJAX or JavaScript as well.

Let’s explore the root causes of these waiting traps. Suppose we have a page that waits until it is loaded to make an AJAX request to a server. This page is not ready to be used until the AJAX request is complete, but Selenium WebDriver thinks it is ready after the initial page load. How do we let Selenium know that the page has loaded and is ready for us to start our automated script?

I’ve timed it, and I know it takes 5 seconds for the page to load.

You will often see automation engineers say this and tend to add something like this to their scripts:

Thread.sleep(5000);

A strategy like this will never work reliably. Because it doesn’t take into account any external variables, and it will slow our tests down unapologetically. External variables that should be taken into account are:

Machine specifications

A slow machine with very little memory will run our scripts much slower than a fast machine. This means that the web element that has been rendered instantly on a fast machine may not actually be there for a few hundred milliseconds on a slow machine. This is long enough to cause an error in our test, but not long enough for it to be instantly obvious to the human eye.

Server specifications

The server that is hosting the website that we are testing is dependent upon the design of the site and it can have varying effects especially when it depends upon a lot of server-side processing. It could slow down significantly when under load. If the site have a high number of concurrent users, the server may have problems servicing the requests, and the responses coming back to the client may take longer than expected.

JavaScript engine performance

JavaScript engine performance can make a massive difference when testing modern JavaScript-laden sites. Something that is rendered instantly in the latest version of Google Chrome could take seconds to render in Internet Explorer 8. To understand how much variance there is in the various JavaScript engines, have a look at the JetStream JavaScript benchmark (https://browserbench.org/JetStream). Try running the test in various browsers. It’s incredible how slow some of the older browsers are.

Networks

In AJAX-heavy sites, network performance is very crucial. If an AJAX request take a long time to resolve, the site under test will take longer to rerender the frontend as a result of the AJAX calls.

If we start looking at all of these potential traps, it soon becomes clear that an arbitrary wait of 5 seconds is never going to be reliable. The reaction some automation engineers have when they are faced with this trap is that they extend their waits and falling into a chain of traps.

Simply telling automation engineers not to use Thread.sleep() is not going to fix the problem either. We need to explain why we should not use Thread.sleep().

In summary, we have identified the main culprits in slowing down our automated Selenium WebDriver tests. In my next blog, I’ll provide solutions to these waiting traps.