What is WebDriver in Selenium? – Selenium Testing Training Online
By DeviQA on Thu Mar 23 2017 00:00:00 GMT+0000 (Coordinated Universal Time)
So, what is Selenium WebDriver?
By designation, Selenium WebDriver is a driver of a browser, that is, a framework which allows you to design programs that control a browser.
What is webdriver in selenium:
Now it's clear why it's pointless to compare Selenium Web Driver with "other testing tools"? Unclear? Then, add the details.
Selenium WebDriver is a browser driver.
Most probably, everyone who has encountered computers, not even an IT person, knows the word "driver". This is such a small program, more precisely a software library that allows other programs to interact with some device. The printer driver allows you to print anything on the printer. The disk driver allows you to read and write data. The network card driver allows you to communicate data with the other computers over the network.
With the driver, users do not work directly. They work with applications that, through the drivers, interact with one or another device. The driver does not have a user interface. Wait, but sometimes there is a user interface to configure the driver? It happens. But this is the interface of the program to configure the driver, not the driver itself. The driver has only a programming interface, its purpose is to allow the application user programs to interact with the device.
So, webdriver in selenium, or simply WebDriver is a browser driver, that is, there is no user interface in it, it is a software library that allows various other programs to interact with the browser, control its behavior, get some data from the browser and make the browser perform some kind of Team.
Based on this definition, it is clear that WebDriver has no direct relationship to testing. It only provides autotests access to the browser. At this point its functions end.
Structuring, grouping and running tests, and generating test reports, provides a testing framework, such as JUnit or TestNG for Java, NUnit or Gallio for .Net, RSpec or Cucumber for Ruby, and so on. Development of tests is conducted in the environment of Eclipse, Intellij IDEA, Visual Studio, RubyMine and so on. The assembly is carried out by means of Maven, Gradle, Ant, NAnt, Rake and so on. Running tests on a schedule and publishing reports is performed by the server of continuous integration - Jenkins, CruiseControl, Bamboo, TeamCity and so on. And all these are independent instruments that are not related to the Selenium project.
However, in the framework of the Selenium project, not only the driver is developed, but several other related products - Selenium Server allows you to organize a remote launch of the browser, using Selenium Grid you can build a cluster of Selenium servers. In addition, there is a "recorder", which is called the Selenium IDE, it can record user actions and generate code that uses the WebDriver interface to perform recorded actions.
But the main thing in the project Selenium is exactly WebDriver, it is a key element of the ecosystem of Selenium.
So why does it have such a primitive interface?
It is because WebDriver is:
A browser driver, that is, a library of a fairly low level of abstraction,The standard for the browser management interface, that is, the minimum set of commands that must be implemented in each browser.
In the development of Selenium WebDriver was originally set a goal - not to include anything superfluous in it. The standard browser management interface should be simple and stable.The set of commands was successively reduced, such "convenience-enhancing" commands as check, uncheck (for checkboxes), select (for drop-down lists) were excluded. All of them boil down to a simpler click command and therefore they are superfluous. Now there is only one redundant command in the WebDriver interface - this is “submit”, but it can be fixed someday.
And thanks to the same simplicity, WebDriver perfectly integrates with any other tools, it integrates into any stack. This is the secret of its popularity and rapid spreading - it does not try to "defeat" other tools, instead it integrates with them.
And what about the ease of use?
This issue should solve by extensions built on the basis of Selenium WebDriver. They should provide an extended set of commands, implementing these commands through a primitive WebDriver interface. In the Selenium distribution, there is the Select class, designed to work with drop-down lists, which is a clear demonstration of how extensions should be built.
Gradually there are libraries that are built on the basis of Selenium WebDriver and provide a higher level of abstraction: Selenide, fluent-selenium, watir-webdriver, Thucidides. Popular frameworks for designing tests allow you to use WebDriver along with other drivers. Among such frameworks it is possible to mention Robot Framework, Capybara and the same Thucidides.
The number of extensions and tools will grow, complexity too. So it may soon happen that you, using a tool, will perform tests without even suspecting that the interaction with the browser is through the Selenium WebDriver driver.
Should I study Selenium then?
To answer this question, I will formulate it differently: who and why should study Selenium, and who better to use higher-level libraries and tools?
1) Whichever tool you use, you need to select the driver that controls the browser. To choose it, you need to know the driver's capabilities - what it can, and what it can't. At this level, Selenium must be mastered by every automation specialist. In this case, the interface WebDriver, if you work with it, there is no need to study.
2) A simple set of commands is easier to learn than "advanced", that is, Selenium is easier to master than its extension. This phenomenon has a downside - if you studied an extended set of commands, then suddenly it turns out that you have mastered the set of WebDriver commands.
3) Extensions are usually linguistic-dependent, because adding convenience involves the use of language idioms, typical methods of organizing code in one or another programming language. The basic interface WebDriver is simple, so mastering it, you can use it in any language, it will look almost the same.
4) Most libraries aimed at improving the convenience of the interface, improve the search tools for elements - additional types of locators, a more convenient way of describing locators and so on. The primitives corresponding to user actions in WebDriver are already good enough. Although, of course, the libraries will implement the typical "bundles", that is, the sequence of these actions, similarly to how it is done for drop-down lists in Select class.
5) If you use tables to describe tests (as in Robot Framework) or a special language for describing at the domain level (DSL, Domain Specific Language) - you do not need to know about the primitives WebDriver. But if you implement fixtures for tests, describe the actions that you can handle in the tables, implement DSL - you will have to work directly with WebDriver, or with some kind of its extension, but not too high-level.
6) And the very last argument, which, I hope, will eventually become less relevant - alas, while good extensions are sorely lacking. They will necessarily appear. Maybe it's you who implement one of these extensions. To do this, you need to study the WebDriver interface. And those who will enjoy the fruits of your work, will be able to work with a higher-level library. In the meantime, you have to directly use WebDriver with small add-ons above it.
In this selenium introduction, we have known about Selenium WebDriver and its possibilities. For further study you can learn selenium online or perform selenium testing training by yourself using information from the official web site or using selenium webdriver tutorials. The instance of the such tutorial is shown below, video: