Faster than a speeding bullet! Easier to maintain than something that’s really easy to maintain! Reliable! That’s what we want from our tests, but how do we get there? This presentation covers key strategies and patterns for writing test suites using WebDriver, a developer focused tool for web application testing similar in spirit to Selenium RC. We’ll cover why it was written, the problems it addresses and how to integrate it into your projects and testing process.
This talk presented by Simon Stewart, creator of WebDriver, still serves as a useful introduction to the tool, even though the talk itself is a couple of years old and WebDriver has moved on since then.
I’ve been experimenting with WebDriver as an alternative to Selenium/Selenium RC, although it is worth bearing in mind that both projects are merging. I’m enjoying getting to grips with WebDriver and am finding that the tight integration between WebDriver and each of the browsers it automates is much faster than Selenium, since it uses the mechanism most appropriate for controlling that browser. For example in Firefox, WebDriver is implemented as an extension, whereas in IE, WebDriver makes use of IE’s Automation controls. In addition to Firefox and IE, WebDriver also supports the following:
- Safari 3 on OSX
- iPhone
- Selenium Emulation
It’s the Selenium Emulation I’d like to touch upon here, what this basically means is that the Java version of WebDriver provides an implementation of the existing Selenium API, and therefore can an be dropped in as a substitute for the Selenium Driver. Here’s an example of how you’d do this:
-
-
// You may use any WebDriver implementation. Firefox is used here as an example
-
// A "base url", used by selenium to resolve relative URLs
-
"http://www.google.com";
-
-
// Create the Selenium implementation
-
// Perform actions with selenium
-
selenium.open("http://www.google.com");
-
selenium.type("name=q", "cheese");
-
selenium.click("name=btnG");
-
-
// And get the underlying WebDriver implementation back. This will refer to the
-
// same WebDriver instance as the "driver" variable above.
This allows for WebDriver and Selenium to live side-by-side, and provides developers with a simple mechanism for a managed migration from the existing Selenium API to WebDriver. I’m still experimenting with it but I have to admit I really like it simplicity.