Selenium WebDriver: What is it?

Selenium Web Driver

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 Driver 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.

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.

Besides Simon, there are Other Selenium Contributors

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

More from Simon Stewart

I had the pleasure of interviewing Simon at the 2018 SauceCon (which this post info was based on), and will be releasing his full audio episode soon.

So be sure to bookmark this post and check back soon for the audio.


Click here to add a comment

Leave a comment: