WebDriver: automated web UI testing

Automating UI testing is not a trivial task, yet it is highly desirable as part of a complete non-regression test suite, which is (as everyone knows by now) a must-have for any project claiming to be agile. This is how I came across WebDriver while looking for ways to automate testing a GXT-generated frontend.

While being quite similar in its goals to Selenium, WebDriver takes a different approach: instead of interacting directly with the application’s JavaScript, it runs totally external to the browser and “drives” it, a bit like SeleniumRC.

Yes, it introduces a platform dependency, but this is mitigated by 2 points: the FirefoxDriver is available on all platforms, and you also have a HtmlDriver which is not platform-dependant, but unfortunately cannot work with JavaScript interfaces.

On the other hand, piloting the browser means you test exactly what the user will see. And depending on the browser is also a good thing because the browser is part of what you want to test! if your application has a glitch on IE which does not exist on Firefox (this is just an example of course…), then you want your tests to find out.

Writing a WebDriver test can be done in minutes. It’s simpy an API, so you can integrate it in any kind of Java code, including a JUnit test suite.

For example:

import ...

public class TestWebDriver {
public static void main(String[] args) {
WebDriver driver = new FirefoxDriver();


WebElement checkbox = driver.findElement(By.xpath("//div[@id='checkbox-id']/input"));

WebElement element = driver.findElement(By.id("submit-button-id"));

System.out.println("Page title is: " + driver.getTitle());

Can’t imagine much simpler than that. Want to test with IE ? Use InternetExplorerDriver instead of FirefoxDriver. Checking iPhone compatibility? Try IPhoneDriver.

As I’m working with GXT, there are a few things to be aware of. You will most often look for elements by ID, but of course the ID you set with GXT’s setId() is not always where you expect it to be. For example, if you set it on a Checkbox, it’s actually attached to the DIV that surrounds the INPUT element, not the INPUT element. This is why, in the example above, I used XPath to select the element, rather than direct selection by ID. When you want to access an element, the best is to have a look at the HTML by using an inspection tool such as Firebug or similar; then you can easily write an XPath expression that will select just the element you need.

WebDriver will eventually be integrated into Selenium 2.0.

3 thoughts on “WebDriver: automated web UI testing

  1. Hi,

    I wonder if you have had any experience of using WebDriver with GXT to navigate through GXT menus. I am attempting to do this to test a project I am working on but WebDrivers simulation of mouseOver events doesn’t seem to be working for me. I can mouse over a menu to pop up its sub-menu, but when I ask webdriver to click on the submenu item the submenu closes as it tries to click it.

    Have you had any experience with this?

    Thanks, Ben

    1. Hi, no unfortunately we did not continue in this direction and we dropped automated UI testing from the project, so I can’t confirm or offer a workaround… But I’d be interested to know if you find a solution.
      Cheers, Olivier

    2. Hi Ben ,

      I am facing the same problem with my app. I am reached to submenu item but its not clicking the submenu item.

      I have tried many options like using Actions Class for mouse movements and Javascript executer as well.

      In my case submenu is opened when user clicks on Menu and its will disappear when user clicks somewhere else on page.

      Please share the resolution if you got one.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.