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.


Approaches to handling AJAX in Web Automation (Selenium)

Unfortunately pretty much places in web applications automation are based on "Magic". What do I mean by saying magic?

Example of Magic:
  1. Test is failing (or some operation is failing) and you don't know why
  2. You are trying something - and is works
  3. BUT you can't explain why the thing you done helps to fix the situation, and is it reliable or not

So, talking about JS/AJAX handling - it's mostly based on Magic for now. Nobody knows how to handle it properly, neither I do.

In this article I'll try to explain how to get rid of Magic in JS/AJAX handling as much as possible. Just theory, without code examples.


Random Data in Test Automation

Using random data can be pretty tricky. As always there are two types of people - who uses random a lot, and who don't.

Let's compare these two ways.

Random No Random
  • Every run you get a new set of data to use
  • Coverage is increasing with each test run
  • You don't need to think about duplicates in data, assuming random is working well
  • Every run is on same (or identical) set of data
  • Pesticide Paradox in place
  • You need to handle duplicates - delete data from previous runs, or in some other way
From the table above using Random seems to be the best choice, but there are some pitfalls.


Why developers are so paranoid about failing Integration tests and Why this is not a problem

When it comes to developers talking about Web Integration tests - you may hear something like "Test should not fail if I move this button" or "If the text on the button changes slightly - test should still pass"

But from my point of view it's ok to fail test because of that. And I would even believe failing test more than passing one.

For a long time I cannot understand the reason of this misunderstanding. And today while reading a book on unit testing - I finally got it.

tl;dr changes in Web Page are more sensitive than changes in API


Testing tip: Google Chrome clearing cache/cookies with a new Chrome User

While testing Web Applications we can frequently face problems related to caching or some old cookies.

The easiest way to clean them in Google Chrome is to use Ctrl+Alt+Delete key combination (or menu Tools -> Clear browsing data...): it will clean all the cookies entirely. And it works in most cases.

But what if you don't want to lose all of your cookies (especially if you use Chrome for your personal needs)? You have two options here:
  1. Use incognito mode. 
    • For this press Ctrl+Shift+N key combination. In this mode you won't have any cache or cookies in place and they won't be saved at the end of session as well.
    • For mode details you can refer official article - Incognito mode.
  2. Create new Google Chrome user and clear everything (or just cookies) for him. 
    • In this way cookies won't be cleared at the end of session, so you may continue your work the next day.
    • For details on creating new user you can refer official article - Manage multiple users on Chrome.
    • User needs to be created only one time, later you can just switch to it and clear.

Personally I prefer 2nd option with new user.

Good luck guys, hopefully this simple tip will be helpful to someone.