What is Selenium WebDriver

If you are just starting looking into Test Automation you must have heard something about Selenium, but not yet sure what it is. Let’s add some context and details to Selenium.

How Test Automation is working

Test Automation is pretty similar to manual testing and is dead simple. You need to make computer do something automatically. It can be done writing new small programs (scripts) which are called Automated Tests. 

Automated Test is actually a small program — piece of code in some programming language which simulates actions of real user.

If we talk about Web — Automated Test would be mainly interacting with Browser to do something like opening pages, clicking somewhere, etc. And this is where Selenium comes into play. 

What is Selenium

Selenium is a set of programming libraries which provides your scripts a way to interact with browser.

Selenium gives you an ability to:
  • Open pages
  • Finding some elements on a page
  • Performing various actions over elements like clicking or entering text into a text field
  • Take a screenshot of what’s displayed in browser
These actions are basically everything what user can do, so it is sufficient to write good Automated Tests.

Better part of it is that’s all this comes at no cost. Selenium is free and open source.

If you want to know more about Selenium and it’s history you can refer to official website — seleniumhq.org. A good place to start is Introduction to Selenium.

What is “WebDriver” part about

WebDriver brings a bit of confusion when you start learning about Selenium.

Why Selenium is sometimes called Selenium WebDriver? Because it’s using WebDriver standard underneath to interact with different Browsers.

But what is WebDriver standard? It’s a standard developed by creators of Selenium. Now it’s a W3C Standard available here — https://www.w3.org/TR/webdriver/.

This standard describes all the actions which user can perform over a browser and all the ways in which browser can respond. 

Given this WebDriver standard is an ideal intermediate level between Selenium libraries and actual browser. 

Selenium WebDriver is actually trying to work with something based on WebDriver standard. And here is where some wonderful things come into place — Browser developers (Google, Mozilla, etc.) were willing to support WebDriver standard and provide special versions of their browsers which can be controlled automatically (via WebDriver interface). These special versions of browsers are usually called Drivers.

Why this concept of WebDriver is good? Because when new browser arises like Edge — we will be able to automate it once it supports WebDriver standard. And no new work will be required from Selenium side.

This was a great effort by Selenium team to make it all work. Thanks to them and browser developers to let this happen.

But why selenium is called Selenium WebDriver, can’t is be just Selenium? This is a bit legacy thing. When Selenium was first developed — there were no such thing as WebDriver, it was working very differently. When new version was ready and WebDriver was in place — it was called “Selenium 2”, and sometimes to highlight how version two is different from the first one it’s called “Selenium WebDriver”. There is also a third version of Selenium which is still using WebDriver underneath.


Why do we need a testing framework (Selenium)

When you start learning automation testing in Selenium in any programming language — you will always get to a point when you need some testing framework (at least you will feel this way).

But why do we really need a testing framework? Is selenium bad without frameworks?

What is a testing framework

“Framework” is kinda buzzword in testing world. Everyone are looking for one, or looking to create one.

Actually what most people are calling a framework is just a set of libraries wrapping Selenium API. 
It’s not such a big thing as frameworks in a typical software development sense. They are just not so mature, contains just some couple of features, doesn’t imply any rules on how to structure the code.

Typical features of testing frameworks

Features of testing frameworks doesn’t vary greatly, usually they just address different areas of software testing and try to ease test development or provide a solution to some routine tasks.
Features of testing frameworks (in no particular order):
  • Reporting — many frameworks include beautiful business-ready reports out of the box. It’s good when you have a report which suits your needs, but can be troublesome to modify it later if you will need some extra information in it.
  • Logging — most frameworks include detailed logging of actions performed by Selenium API and other things. It’s good in any way if coverage is good enough. It can ease debugging and support of tests. Sometimes logs also include screenshots or video of test execution.
  • Validations — some frameworks address how you validate things in tests. Proper validations may ease the Reporting and Logging mentioned above.
  • Page and Elements handling — some frameworks dictate how pages and elements should be organized. This is not a technical decision, but rather a try to structure and organize the tests. Sometimes it makes sense, but some decisions are very subjective and represents a specific opinion of a framework’s author.
  • Waits and AJAX handling — some frameworks try to give you all-in-one solution to all the AJAX and async moments in tests. There is no silver bullet, so if your framework tells it has one — be careful with this. More mature frameworks doesn’t give you all-in-one solution, but rather give you good opportunities to make Waiting easier.
  • Browsers handling — most frameworks try to ease working with different browsers. And many of them did a great job with this. But still sometimes you will be in situations when you will need to add something custom to make it work everywhere. Nothing bad about frameworks, but just remember — that you need to do something on your own and not depend on others.
  • Locating elements — some frameworks question the way you locate the elements and try to give you their own approach on this. Again this kind of features is pretty subjective and won’t suit everyone’s needs.
  • Parallel runs — some frameworks state that you can run tests in parallel and provide you some things to do this. Parallelization is a tricky area. Usually it’s more about Continuous integration and the way you run the tests rather than Testing frameworks.

The need in testing framework

There is no vital need in testing frameworks.

All the mentioned features are not a vital things to include in your tests, they just cover something which you may need to do yourself.

So the frameworks won’t make your tests better, they just speed up your work and provide some specific solutions to everyone’s problems. 

Selenium is not bad in any way and doesn’t require you to use frameworks. Actually all the interaction between the browser and the pages is performed by Selenium and not the frameworks. It means that there are no any advantages on using one framework over another in terms of interaction with pages — they all use the same Selenium API underneath.

So what to do if you start learning automation and are thinking about which framework to choose? My bet is — get anything popular and wide-spread and start with it. Once you will meet some problems you can start looking into changing the framework or writing your own.