Why WebDriver Is An Interface not a class or an abstract class?

“Why WebDriver is an interface not a class or an abstract class?” This is a frequently asked interview question as well as an important concept of Selenium WebDriver.

Anyway the answer of this question depends on how much you understand Interface and Abstract class concepts in Java and how and when to use.

There are plenty of posts on Difference between Abstract class and Interface, but the actual question “When to use what?” remains confusing for many specially for testers like us.

I follow a simple understanding about when to use Interface and abstract class that “If you do not know anything and dependent on other’s help then use an Interface. If you do know something but still need help of others, use an Abstract class.“.

Usage of Interfaces and Abstract classes is needed for better architectural design for better scalability, maintainability and less painful to make a bigger change.

Let’s discuss Why Selenium WebDriver developers made WebDriver an interface.

Let’s start this post with a small story.

There are three “builders” and all builders do the same work such as building a house, interior designing, furniture works , paintings etc. But all three builders have their own style of performing same works which are not known to outsiders/world.

There is an entrepreneur who wants to start a “Construction service provider” company and wants to onboard three builders discussed above. All three builders were ready to be part of the entrepreneur ‘s company but they kept below conditions:

  1. We will not share our techniques or style of getting work done with you. You just need to give the tasks to do and do not care how we will do that.
  2. We may not know all the terms used in each others business. So there will be a mediator between us who understands everything of both sides. Each communication should go through mediator so that we no need to invest time on understanding each other’s terms.

The entrepreneur  accepts all terms and conditions given by builders and launches company. Story over!!

The more or less same story with Selenium WebDriver as well. The purpose of Selenium WebDriver to automate browsers but they do not know how each browser works internally.

Every browser has their own logic to perform browser’s actions such as Launching a browser, closing a browser, loading URL, handling different type of web elements. Same operations are performed in different ways by different browsers.

Without knowing internal working mechanisms of browsers, Selenium WebDriver developers can not write codes to perform actions. If they get to know the internal mechanism some how, it will be difficult to manage when internal mechanism changes and this should not break flow for other browsers.

So to make it simple, a contract is placed between Selenium WebDriver developers and browsers and that contract is in form of WebDriver. A WebDriver consist of all related basic methods which could be performed on a browser.

Official Java doc of WebDriver summarize it very well as :-

The main interface to use for testing, which represents an idealised web browser. The methods in this interface fall into three categories:

  • Control of the browser itself
  • Selection of WebElements
  • Debugging aids

Key methods are get(String), which is used to load a new web page, and the various methods similar to findElement(By), which is used to find WebElements.

Currently, you will need to instantiate implementations of this interface directly. It is hoped that you write your tests against this interface so that you may “swap in” a more fully featured browser when there is a requirement for one.

RemoteWebDriver is direct implemented class of WebDriver which are furher extended by browser Specific classes like ChromeDriver, FirefoxDriver etc. There is a misunderstanding that RemoteWebDriver has all the logic to perform actions on browser and browser specific classes like ChromeDriver gives missing implementations. It is not correct. In fact there is no implemented classes of WebDriver interface provided by browsers. Everything is done via browser executable servers.

All implementations of WebDriver that communicate with the browser, or a RemoteWebDriver server shall use a common wire protocol called JSON Wire Protocol. This wire protocol defines a RESTful web service using JSON over HTTP. So the role of RemoteWebDriver to construct a request for specific browser o perform. All request are sent to browser specific servers i.e. executable files.

WebDriver could be an abstract class as well but idea behind making WebDriver is an interface for better architectural design. I have come across below lines form some source :-

“There are a number of situations in software engineering when it is important for disparate groups of programmers to agree to a “contract” that spells out how their software interacts. Each group should be able to write their code without any knowledge of how the other group’s code is written. Generally speaking, interfaces are such contracts.“

So for the best architecture, WebDriver is an interface.

If you have any doubt, feel free to comment below.If you like my posts, please like, comment, share and subscribe.#ThanksForReading

#HappySelenium