Meet Simon Stewart, the creator of Selenium WebDriver.
If you are involved in test automation at any level, you’ve probably heard of it.
It’s kind of a big deal.
What is Selenium WebDriver
Simon summarized WebDriver as:
- A library for browser automation
- Provided for almost every programming language
- You must manage browser version
- Does not have a built-in framework for actually running tests
- Relies on language proved tools like Jasmine, Junit
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. Although Selenium is primarily used to help test a web application but can be used for any task where you need browser automation.
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.
What Programming Languages can you use to create your Selenium Webdriver tests
As you’ve seen Selenium is really just an API. One benefit of this is that you can use pretty much whatever programming language you want to create your automated test with. Here are the language bindings currently supported by Selenium:
- Selenium WebDriver Ruby
- Selenium WebDriver C#
- Selenium WebDriver Java
- Selenium WebDriver Python
Noticed I said *supported. You can also find non-supported implementations of the Selenium WebDriver protocol for exotic language like Haskell
Running Selenium against Browsers
In order to run your selenium test against different browsers, you will also need to use different browser specific executables that WebDriver uses to control the browser.
- Chrome: ChromeDriver
- Firefox: GeckoDriver
- Microsoft Internet Explorer: IeDriver
- Microsoft Edge: EdgeDriver
- GhostDriver: GhostDriver
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?
Jason Huggins created Selenium while working at ThoughtWorks, and it was a revolutionary invention at the time.
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.
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.
Dave Haeffner: The Selenium Webdriver Java Guidebook: