Meet Simon Stewart, the creator of Selenium 2.
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 it 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, it is not a standalone testing tool or testing framework.
Selenium WebDriver is an open-source API that allows you to programmatically interact with a browser on an operating system the way a real user would.
Although it is primarily used to help browser testing of web applications is can also be used for any task where you need browser automation.
WebDriver tests can be programmatically created using multiple different programming languages. You also can configure the Proxy Server to know which browser to use for your test run.
Some folks also call it Selenium 2.
In a nutshell, it's an API (not a testing framework) that allows you to open a browser window and drive it using keyboard and mouse emulations just like a real user would.
To automate interaction with the fields of your application you can use multiple ways to identify the elements under test like:
- By Class Name
- By Css Selector
- By Id
- By Link Text
- By Name
- By Partial Link Text
- By Teg name
- By XPath
Remember the keyword here is a web browser.
So is it just for testing browser applications—- YES!
It doesn't support thick client applications or APIs automation.
Architecture of WebDriver
There are four main parts that make up the architecture.
- First, you have the API which is a set of commands you can use to interact with WebDriver
- Next, you have a Library that contains the API as well as program languages specific implementation libraries for common languages like Java, Python, C#, etc.
- To actually control the web browser under test you have a driver. These drivers are ideally created by the browser vendor themselves following the W3C standard.
- Finally, you have a framework that contains the Selenium API as well as other libraries needed to create a fully functional automation framework like test runners, logging, test data creation etc.
What Programming Languages can you use to create your Selenium Webdriver tests
As you've seen this testing library is really just an API that was developed so that it drives the browser under test as if it was a real user interacting with a site.
One benefit of this is that you can use pretty much use whatever programming language you want to code your automated test with. Here are the language bindings currently supported by Selenium:
- Selenium WebDriver Ruby
- Selenium WebDriver C#
- Selenium WebDriver Java
- Selenium WebDriver JavaScript
- 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 the origins of developing this solution and 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. It 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 Remote Control RC
Before Selenium WebDriver there was the original Selenium, which was based on using JavaScript to control a browser’s actions.
Jason Huggins created the original version 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 the new version up to a point where it could replace the original.
What about Selenium IDE?
On August 8, 2017, Firefox released version 55.0, and Selenium IDE officially died.
From Firefox 55 onwards, Selenium IDE no longer worked.
But about a year ago I began hearing another rumor about Appitools taking up the cause to resurrect Selenium IDE.
So if you haven't heard yet there is now a new and improved version of Selenium IDE. Read all about it in my post the Stunning Return of Selenium IDE (Sweet Dream or Nightmare)
Selenium IDE can be run from your CI/CD pipelines using the command line runner.
What about Selenium Grid?
Using a Selenium grid allows you to save time by spreading your test across multiple machines generating multiple browser drivers sessions.
This means you can run your test in parallel, which reduces the amount of total time to run your full automation test suite.
If you want to learn more check out my post on Selenium Grid Getting Started Guide (Plus 2 Must Use Helper Tools)
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.
Also if you're wondering about Selenium Server which is needed in order to run Remote Selenium WebDriver. Selenium 3.X is no longer capable of running Selenium RC directly. How it works now is that it does it through emulation and the WebDriverBackedSelenium interface.
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 web driver example: WebDriver.findelement will return an element, and you can keep hold of that reference.
Often I look at people's tests, 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 TestGuild Automation Podcast (Formally called 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:
