“Don’t wait. The time will never be just right.” Napoleon Hill
Element not found
Are you testing a web application using Selenium and keep getting an [error] Element .. not found error message? One way to work around this and similar issues is to use a waitFor command.
Why the Pause command stinks
You may be thinking, “Wouldn’t it just be easier to use pause commands throughout my script?” In rare instances, a pause command may be the way to go, but in most instances it’s a very poor choice.
When using a pause command in your test, you have to try and make the test wait just a little bit longer than what you believe the longest anticipated response time will be.
The problem with this, of course, is that the response time could be considerably longer than anticipated – which means you end up bumping up your wait to be even longer than the longest expected delay.
Those long pause times will slow your test run time considerably, which is not cool. The solution is to use a method that’s flexible enough to synchronize with longer and shorter delays.
WaitFor commands are not hard waits; meaning that they will, by default, wait up to 30 seconds to find an element, but if they find an element before 30 seconds, they continue without waiting the remainder of the time. (If you’re familiar with HP’s Quick Test Professional, it’s similar to an objects exist method or WinRunner’s generic obj_wait_info statements.)
Why use Synchronization Points?
In test automation, this concept is often referred to as synchronization. Adding synchronization points in your script facilitates your test when you need to wait for a response from an application. This is important — because when testing a web application, server response times can vary for any number of reasons.
To help make your scripts more reliable, you should get into the habit of using synchronization points like one of the many waitFor commands available in Selenium.
For this sample test application I use AJAX to populate it. More often than not, an Element not found error occurs when running a test against this application. This is due to issues with the element not being loaded into the DOM because it’s in the process of being rendered in your browser. One way to work around this issue is to use a waitFor command.
Let’s check out a quick example:
Selenium has a bunch of waitFor commands. In this example we’ll use the waitForElement, but you can use whichever command works best for your situation. To make this quick I’ll use the Firefox Selenium IDE, but you’d use the same waitFor methods if you were coding using the Selenium APIs.
- In Firefox, start the Selenium IDE.
- For the Base URL, navigate to:
- From the HPSupport.html page, enter the following values:
- Select your tool & version = QTP11
- Is this supported = DELPHI_ADDIN
- Right click on the first row, first cell, Delphi Controls CLX and select Show All Available Commands>asserText css=td Delphi Controls CLX.
- Stop recording. Your IDE Table results should look like this:
- Click on “Play current test case”.
- You should see the error [error] Element css=td not found. (If you don’t see this error, it’s ok-you’ll still want to add a waitFor, however. It’s a good practice since response time will vary for each test run.)
Add a waitForElementPresent command
Now, let’s add a waitForElementPresent command and rerun our test.
- Right click on the assertText command and select “Insert New Command” from the menu.
- Next, enter to following:
- Command = waitForElementPresent
- Target = css=td
- Click on the Find button, this should highlight the first cell in the first row.
- Rerun the test by clicking on”Play current test case” –the run should pass and your log should be error free!
That’s the basics on how to use the waitFor commands in Selenium. Stay tuned for more Selenium 101 posts in the coming year.
To get started using Selenium WebDriver in Java or .Net check out my other post: