•  Does your Automation test cases taking more time for execution ?
  •  Is your Test framework supporting only Firefox browser?
  •  Finding it difficult to automate your test cases in Chrome ?
  •  Not able to get proper solutions on community for your queries related to chrome   automation ?
  •  Wish to write your scripts as easy as it is with Firefox ?
  •  How implementation of firefoxDriver and chromeDriver different?
  •  Wish to explore the internals of Cross Browser implementation?

Lets find out solutions to all these questions right here in this blog.

Whenever given an option to Automate test cases, we always tend to use firefox browser by default to run our test cases. Automation testers don’t want to take pain to run these test cases on chrome to support cross browser implementation. It is because of some limitations and existing issues in chrome.But here we are going to find out how one can completely overcome these issues, support chrome for their test execution and ultimately start preferring chrome over firefox.

We know that while automating our test cases using Selenium Webdriver, we use the Client APIs – FirefoxDriver and ChromeDriver for firefox and chrome browser respectively.One basic fact about these drivers is: ChromeDriver is faster than FirefoxDriver, and FirefoxDriver is intelligent than ChromeDriver.

Keeping this fact in mind lets discuss about the issues which we face in chrome and their respective solutions.

1. Locator Selection: Locators creation should be very precise. We need to make sure we give the innermost child while creating locators.
This will reduce the scope of elements click and hence increasing the click events probability. 
eg: Lets consider this portion of a pages’ DOM


Instead of creating the locator as:

we should be creating as:


2. Waits in Clicks: In chrome, during the page loading if we are trying to click an element on the page, it might throw ‘Element not clickable’ error. This error usually occurs because when the click event actually happens the element adjusts itself to its actual position(position of the element after rendering). In chrome browsers elements animate (which is not visible to the naked eye) before its settles down to its actual position and when trying to click the element, it actually changes its location , hence click event does not happen and it throws error. 
To avoid this we can put the click event in the waitFor closure.

This will ensure that until the actual click happened on the element, it will not come out of the closure. 
Note: Not all clicks require waitFors{} . Only those which fall into the category explained above needs to be taken care of.


3. Closing of Popups: Unlike firefoxDriver, chromeDriver is unable to switch to a different browser from the current browser instance ,if we have an unclosed popup on the current browser. 
Also, if a popup is already opened on a browser, chrome driver cannot initiate any events on the elements present in the browser which is at the background until the foreground popup is not closed. 
We need to make sure to close all the popups after we are done working with it.


4. Use JS close instead of Selenium close: We have an issue with chromedriver’s close() method. Lets say we have two browsers opened(Browser_A and Browser_B). On closing Browser_A, we should get a message on Browser_B that Browser_A is closed. 
When we use selenium close, even though it forcefully closes the window, it does not intimate the driver instance about its closure, because of which the other browser does not get any alert. 
On the contrary JavaScript way of closure does the trick. 
So we need to make sure that wherever we have a dependency of two browsers, we need to use the Javascript’s close.

instead of selenium’s close

5. Storing variable instead of JS Object: We have an existing issue with chromedriver that it does not store a large length of JS Object into a variable. 
We need to make sure that instead of storing the whole object in a variable, going forward we need to store the actual variable on which we need to work. 
eg: Instead of using

we need to use:


6. Use Interact instead of Geb’s Click: Sometimes Geb’s click wont work if the element is partially visible, but the middle of the element is overlapped by some other element. 
In this case chromedriver becomes unable to click the middle of element. 
In such case we can use interact/ Actions class to move the mouse to the corner most position of the element and then moveing the offset by a liitle to make sue that the corner of the element gets clicked.


7. Browser Focus: For triggering any actions on web elements in chrome, that element should always be in viewport focus(visible to the eye). It works fine in Firefox even if element is not in focus, but for chrome we need to scroll our focus till that element comes into the browser’s focus.


Following these simple guidelines in our Project has tremendously increased our efficiency. Test Case execution time has drastically reduced by 25 %. Automation testers are preferring using chrome over firefox to run their test cases.

So why not make Cross Browser Testing EASY !!