Best practises - Selenium WebDriver/ Java

Intermittent failure in Selenium Test cases ?
After clicking the drill down sometimes web-elements are not found causing all summary table test cases to fail.
Common Root Causes
1) Prefer Selection By.ID className  then By.cssSelectior and only if all else fails use By.Xpath
Selection by CSS By.CSSSelector should be preferred over XPath as this is more stable as it is natively supported by browser . XPAth is an abstraction provided by Selenium and not as performant. If XPath is used make sure that you have hand written the XPath and it is performant and not generic in that it has to to brute force search through the entire DOM to find your element.
Where ever possible , use By.ID, else By.CSSSelector and in case of no other option use XPath after proper testing.
You can use FireFinder plugin for FireFox (first add FireBug) to test your CSS or Xpath (if there is no way you can select by CSS)
For example this XPath to finding the drill down element 
//*[@id='scTableTest_Site-PLMN-PLMNMRBTS-255-sitecreation_netact1']/td/div/img [@src='/SiteCreation-Table-portlet/images/openDrillDown.png']
can be reduced to this more efficient CSS - #scTableTokyo-PLMN-PLMNMRBTS-400-sitecreation_netact1 > td  > div  > img +img
2. may not click if element is not visible in browser view port
If an  element is not visible in the browser viewport , clicking on it should not be possible and test case should fail. Earlier versions of webdriver used to do implicit scrolling. However this is not consistent and is being debated. It is better not to rely on this. One way to make sure the element is clicked is to use the Selenium feature of directly invoking JS on the browser
 ((JavascriptExecutor) driver).executeScript("arguments[0].click();", rowElement); 
 return ;

3. Design and model your Selenium Java Code
More often there is no structure or design applied to Unit test classes. This may be okay for JUnits testing Java classes, as the design of the Java class is reflected in the test cases. But when we write integration test cases or GUI test cases with JUnit or TestNG using Selenium WebDriver writing like this leads to un-maintainable and very brittle code. The application should be logically structured . This way there is no code duplication and code bloat which otherwise keeps on growing with IDs, CSS paths or xPath's everywhere
Some good links - PageObject Pattern
4. Dont Sleep-- for Long, if you need to, do sleep for a short time wake up check and retry ( Retry pattern)
Understand and use Selenium implicit waits (common for the whole webdriver instance) or explicit waits
Example - 
WebElement rowElement = (new WebDriverWait(driver, 10).until(
Note - Wait Retry pattern is very important for Stability; All finds should be retired at least three times as a rule of thumb. Depends also on your test case and modelling context as well
Implicit and Explicit wait: check these links
In case you have to sleep create a helper that sleeps for say 100 ms , checks and sleeps (while loop with a retry count ) 50 *100 = .5 seconds , so that if an element appears before , time can be saved


Popular posts from this blog

Long running Java process resource consumption monitoring , leak detection and GC tuning

OpenLayers Advanced Clustering and Setting dynamic images for OpenLayer Styles via Ajax

Java Script Development Guidlines