Selenium WebDriver: What is it?

Selenium Web Driver
TestingGuildTopAd

Selenium WebDriver: What is it?

Meet Simon Stewart, the creator of Selenium WebDriver.

Simon Stewart web driver

If you are involved in test automation at any level, you’ve probably heard of it.

It’s kind of a big deal.

First and foremost, Selenium WebDriver is not a standalone testing tool. It’s an API that allows you to programmatically interact with a browser the way a real user would.

Selenium WebDriver is often referred to as Selenium 2. Selenium drives a web browser using keyboard and mouse emulations.

The key word here is browser.

Selenium WebDriver is just for testing browser applications. It will not work against thick client applications or APIs.

Why was Selenium WebDriver Created?

When I asked Simon about WebDriver’s origins, he said it actually began as an implementation of the facade design pattern.

There were other tools out there, and they were perfectly fine to help automate browsers, but their APIs were clunky.

Additionally, some of the existing tools grossly violated the rules of object orientation. Selenium WebDriver was born out of the desire to have an easy-to-use, readable API that also followed solid, object-oriented principles.

Simon Stewart talks about the past, present, and future of Selenium in my interview with him at SauceCon:

What about Selenium 1?

Before Selenium WebDriver there was the original Selenium, which was based on using JavaScript to control a browser’s actions.

Jason Huggins created Selenium while working at ThoughtWorks, and it was a revolutionary invention at the time.

But as some of you may remember, Selenium started to become really slow as time went on. It was unstable and had tons of bugs, and it became pretty clear that the JavaScript sandbox was going to become a limiting factor for the project at some point.

Soon after, Simon decided to develop WebDriver up to a point where it could replace the original Selenium.

What is the Future of Selenium?

Modern web browsers are getting more and more complicated, and not all of them are open source.

Many of the changes the Selenium open-source developers want to make, and with the level of privilege they have, will require fairly deep integration with the browser, and the only people who are really in a position to do that are the browser vendors.

So the next milestone is clearly the W3C spec.

I think the most interesting thing about the W3C WebDriver spec is that it’s where the Selenium project ceases to be around one obscure body of open source developers and becomes an industry standard—which, in turn, makes it incredibly hard for a single individual to exert any form of control over it.

This is a good thing.

Since Selenium is going to be a Standard, Why isn’t Everyone Using It?

There are a host of new tools out there that for some reason don’t leverage Selenium WebDriver.

It seems to me they are trying to reinvent something that already exists.

Rather than trying to replicate the WebDriver functionality that already exists, I’d like to see them utilize the WebDriver that’s baked into the browsers.

In my opinion, they’d be better off focusing on functionality like getting accurate timing information, setting breakpoints, and seeing when errors are thrown in JavaScript. They should let the WebDriver spec be responsible for controlling the browser and doing things like keyboard and mouse simulation.

The Rest is History

What Simon initially thought was going to be a few months of work has turned into a ten-year project with multiple contributors changing the way we automate browsers.

Simon’s Actionable Automation Advice for Using Selenium WebDriver

Simons actionable Selenium WebDriver advice is first if you have an XPath that is literally a path for your document, Html, body, etc. You’re doing it wrong! Stop, think, there’s a better way of doing this.

The second piece of advice. For a Selenium webdriver example: WebDriver.findelement will return an element, and you can keep hold of that reference.

Often I look at peoples test, and they got driver.findelement the same element send keys, driver.findelement, the same element submit and you scratch you’re head.

Each WebDriver call is an RPC and if your using system like source, for example, you’ve just gone out over the Internet. And the problem is you can just keep hold of the element reference and your good.

So really that should be WebDriver.findelement and keep hold of that reference — element.clear, element.sendkeys, element.submit and you’ve reduced the amount of work you’re doing. You’ll have sped up the tests and if you find that finding stale elements exceptions being thrown that means the applications is changing the state in a way that you weren’t expecting.

And as a tester that should just set off all sorts of alarm bells, or is a developer I should be setting off alarm bells going like how come I don’t know the state of the application? So that stale element exception is not a problem. It’s an opportunity to go and find out more about what is going on in the application.

Besides Simon, there are Other Selenium Contributors

Here are a few other TestTalks interviews I’ve had with other Selenium contributors like:

Jim Evans who is one of the key contributors to the Selenium project. He is also the man behind the Selenium .NET bindings, and the Internet Explorer driver.

Manoj Kumar who is a Principal Test Automation Consultant and a Steering committee member of the Selenium Project:
Jason Huggins is the founder of Tapster Robotics and co-founder of Sauce Labs and created the original Selenium, an integrated tool for automated website testing:

Dave Haeffner: The Selenium Webdriver Java Guidebook:

For a list of selenium resources and selenium webdriver tutorial that includes info on learning selenium language bindings like selenium webdriver python check out my post on
Click here to add a comment

Leave a comment: