The Issue

Some pages will load their elements dynamically, meaning a regular Ruby & Watir-Webdriver command may fail due to the element not yet being present. We have previously discussed using Explicit Waits; we will now be looking at how to effectively use Implicit Waits to test our browser.

The Answer

An implicit wait will allow you to hardcode your wait into your automated test script; while we generally prefer Explicit Waits, Implicit waits can be useful for any scenario that you find requires a hardcoded sleep. Even for your own reference while debugging, a hardcoded sleep can help to determine the load time of an element. Here is what the command looks like:

The number after our sleep tells the browser how long to wait before executing the next command. Lets look at an automated test script that utilizes this command.

The Code

The SAP Fiori trial site contains a loading spinner that lasts a few seconds between pages. Attempting to immediately click something on a desired page will result in a failed validation, due to the element having not yet loaded. We will use an implicit wait to get around this.

The Result

The SAP Fiori Homepage we will be running our implicit waits on.

The SAP Fiori Homepage we will be running our implicit waits on.

We can save our automated test file (TestDynamicPages.rb) and run the script:

  • Browser opens
  • Browser navigates to SAP Fiori trial page
  • Browser sleeps for designated time
  • Clicks the Agree page
  • Sleeps for designated time
  • Clicks the My Time Event page

The Takeaway

Its always good to have another tool in your testing arsenal, and an Implicit Wait from Ruby & Watir Webdriver will give you another option to test dynamic pages. They provide a robust way to ensure you are given enough time for your desired interaction to occur.