Handling Waits in Selenium WebDriver

While testing the websites, we can’t really quantify the exact response time which an action takes on a web page. So we need to handle the waits between actions on a web page while writing selenium scripts.

So lets see how can we implement a wait strategy which is robust, stable for long run for the scripts. If we think of a Selenium script, it is nothing but a JAVA program (assuming you are implementing it in JAVA); So  what about pausing a java program for some time. So one way is following –

Thread.sleep(number_of_miliseconds)

Thread.sleep(5000L);

But, as I said above we can’t really quantify the time, or we can give maximum time here. But then you will end up spending a lot more time in execution, but purpose of automation is to minimize time. Lets see what are the issues with above strategy-

  1. You can never predict the exact wait time
  2. It increases overhead
  3. It may not work well with all computers

So to handle this, Selenium provides two types of wait strategies-

  1. ImplicitlyWait
  2. WebDriverWait

ImplicitlyWait-

As we know in Selenium every driver.findElement() command looks for the WebElement in the web page. Implicitlywait tells webdriver to wait for an element if they are not immediately  available, So that Webdriver does not throw NoSuchElementException immediately

driver.manage().timeouts().implicitlywait(20,TimeUnit.Seconds);

So the difference between this and sleep strategy is that here maximum threshold is 20 seconds (can be as per your choice). So if element is available in lets say 4 seconds, it wont wait for other 16 seconds. and the beauty is you dont have to write this command again and again, once you write this command, it is set up for complete WebDriver session.

WebDriver Wait or ExplicitWait-

Many times, we need to explicitly wait for some condition to finish and then to proceed the execution. So this time its not only about waiting for an element to come in DOM. so here is what you have to do for it-

WebDriverWait wait=new WebDriverWait(driver, 30);
//Now use this object to apply wait with conditions
wait.until(ExpectedConditions.textToBePresentInElement(driver.findElement(By.xpath(“”)), “expected text”));

So here, webdriver will poll every 500 seconds to check text in given element and maximum threshold here is 30 seconds. WebDriverWait class provides almost every expected conditions which you can come across while creating script. lets have a look by below snapshot-

wait

Some times we come across situations where the provided expected conditions are not enough and we have to create our own condition. That can be done in following manner-

WebDriverWait wait=new WebDriverWait(driver, 30);
//Now use this object to apply wait with conditions
wait.until(new ExpectedCondition<Boolean>(){
@Override
public boolean apply(WebDriver driver){
return boolean_return_type_of_your_condition;
}
});

So every expected condition has an Apply method, which you need to override with your custom condition.

So this is how you can handle waits with your Selenium WebDriver scripts. Hope it has helped you understanding and implementing it. 🙂

Advertisements

Proof-read your Selenium WebElements

Selenium is a suite of software for automating browsers. It provides an API in different programming languages for automating browsers, by mimicking human actions with browser.  Locators are the part of browser automation testing. Locator tells Selenium which html element of a web page, Selenium has to perform action. These are the following locator strategies included in Selenium.

Locator Strategies-

  • ClassName
  • Css Selectors
  • ID
  • Link Text
  • Partial Link Text
  • Tag Name
  • Xpath

Selecting the correct and good locators, increases the robustness of your automation script. Good locators are –

  • Unique
  • Descriptive
  • Unlikely to change

Always prefer to access the elements using IDs and Classes, and if you have to specifically traverse an element in the web page, Go for CSS Selector and Xpath. Sometimes it happens that we create our own Xpath and CSS selectors, and as a human it does not always happen that we have create a correct CSS selector or Xpath.

Verifying the Locators

So how about verifying your locators before putting them in to your script. I have found a Firefox Add-on i.e. “FireFinder” using which it is possible and quite easy. I assume that you already have Firebug installed in your Firefox browser. Following are the instructions to install and use this add-on-

  • Open your installed Firefox browser and search for “FireFinder” add-on, as soon as you will reach to the FIreFinder add-on screen you see something like below:FireFinder_Installationpage
  • After installation, Firefox will ask for restarting the browser. After restarting the browser you can see that there is a FireFinder option in your FireBug toolbar.FireFinder_Toolbar
  • Now your browser is ready to use the Add-on. I will create a CSS Selector manually for Gmail Email Id field and verify the CSS Selector.
  • After inspecting the Gmail Email id field, I found that id for the Email field is “Email”. So I will create a CSS selector i.e. “input[id=’Email’]”. Now verify this selector by entering it in FIreFinderFireFinder_Highlighting

So this is how we can validate our customized CSS Selector and Xpath, even before executing our automation scripts. This will reduce the time spent in creating the locators and give confidence to our automation scripts.

I hope this has helped you in understanding the locators in Selenium. Your comments and feedback is most welcome. 🙂

Xpath : a path to your WebElement locators

Many times I hear from people that my Selenium script is not executing properly for different browsers. So we keeps on complaining that selenium is not really identifying our web elements on different browsers. But if we look at it deeply, it’s not selenium; it’s the locator engine of your browser which is not able to understand your WebElement’s locator.

So lets talk about the browser’s locator engine, Every browser has different mechanism to process your locator i.e Xpaths, Css Selectors, Ids etc. So when we try to execute our same script on different browser, it might not identify the same element it was  identifying on previous browser. So we need to create locator which has basic requirement to be robust for almost all browsers-

  • Relative xpath over absolute xpath.
  • Avoid using xpath or css selector if element itself has some unique attribute i.e. id, name, linkText, title.
  • Verify your xpath before executing script (Saves a lot of time).
  • Prefer using Css Selector over xpath if you creating your script for headless browsers like PhantomJs.
  • Create your customized locator if needed.

Lets understand the syntax of an xpath-

When you have a unique attribute for your targeted locator

//tagname[@attributename='attribute value']  e.g. //input[@id='username']
when you don't aware of specific tag name
//*[@attributename=’attribute value’] 

When you have no unique attribute but a parent of that element has some unique attribute

//parentTagName[@parentattributename=’attribute value’]/targetedElementTagName
e.g. //table[@id=’userTable’]/div
use double slash "//" if you are targeting to a grand child

Some  Xpath methods-

  1. Contains() – When you want to select an element which contains some part of its attribute, for e.g. you wan to select an element which contains text “user” in its id-
    //*[contains(@id,’user’)]
  2. starts-with() – When you want to select an element whose attribute’s value starts with some text. For e.g. you wan to select an element whose ids starts with text “user”-
    //*[starts-with(@id,’user’)]

Handling text attribute – Sometimes we use Xpath methods with text attribute and it does not work. we need to understand that text is not an element’s attribute, its a function. So if you are applying above conditions for text then it would look like as below-

//*[contains(text(),’user’)]
//*[starts-with(text(),’user’)]

Handling parent-child nodes

  1. accessing immediate parent – //tagname[@attribute=’attributevalue’]/parent::parenttag

e.g. //div[@id=’someid’]/parent::span – (here we are accessing parent span of some div child)

2. accessing grand parent – //tagname[@attribute=’attributevalue’]//ancestor::grandparenttag.

if there are multiple grandparent with same tag you can give index like below- //tagname[@attribute=’attributevalue’]//ancestor::grandparenttag[1]

3. accessing nth-sibling (following and preceding) – Suppose we have a div element and its six child of tag span. We have id of first span but want to access 5th span based on first-

//span[@id=’first_span_id’]/following-sibling::span[5]

for preceding sibling – Suppose we have a div element and its six child of tag span. We have id of 6th span but want to access 1st span based on 6th

//span[@id=’sixth_span_id’]/preceding::span[5]

So this was just little information about xpaths, creating customized xpath etc. I will be posting another blog with detailed information about creating  Css Selectors. Feel free to post comments in case of any concerns.

Happy Coding 🙂