5 top casting options in Selenium WebDriver API

Selenium WebDriver API hierarchy. Top casting options — which of them works and which don’t, and why.

Introduction :

WebDriver API is one of the 3 components provided by Selenium. It is an interface that has many declared methods that help perform certain actions on the browser.

In this article, we will investigate all 5 top casting combinations while creating a browser driver object (ChromeDriver, EdgeDriver, FirefoxDriver, etc.) and see why they are not all suitable to use.

This is also very often asked in automation testing interviews, to explain the WebDriver API hierarchy and the different type castings.

SearchContext interface :

SearchContext is the parent interface to WebDriver and WebElement interfaces. it has two methods : findElement() and findElements().

WebElement interface :

WebElement is an interface and it has several methods that help performing certain actions on elements on the web page. Every element on a web page is known as web elements in Selenium.

WebDriver interface :

WebDriver is an interface. WebDriver API is the one that launches and performs actions on the browser. It has methods to manipulate the browser components.

It has child classes that we use extensively, such as : ChromeDriver, ChromiumDriver, EdgeDriver, FirefoxDriver, InternetExplorerDriver, RemoteWebDriver, SafariDriver etc.

RemoteWebDriver class :

RemoteWebDriver class is the concrete class that implements all the declared methods of its parent and grand parent interfaces.

ChromiumDriver class :

ChromiumDriver class’s direct parent class is RemoteWebDriver. It has child classes such as ChromeDriver and EdgeDriver.

5 different top castings to create a driver object :

Now, let’s analyze different type castings among the WebDriver API while creating a browser driver object. And we will see why some of them don’t work. Here, we will take ChromeDriver as example browser driver class.

1. SearchContext and ChromeDriver top casting :

SearchContext driver01 = new ChromeDriver();

In this case, the driver will have only two methods : findElement() and findElements() coming from SearchContext. This top casting is kind of moot, as we won’t be able to launch the browser to perform any action.

2. ChromiumDriver and ChromeDriver top casting:

ChromiumDriver driver = new ChromeDriver();

Here, only ChromiumDriver specific methods will be available to the driver. That means, the ChromiumDriver class provides certain methods which are useful to a chromium browser i.e ChromeDriver and EdgeDriver.

As ChromiumDriver inherits from RemoteWebDriver class, the methods such as get(String url), findElement(By locator), findElements(By locator), manage(), close(), quit() etc. will be available to the driver object reference.

So if one wants to perform cross browser testing, it won’t be possible.

3. ChromeDriver class : (not a top cast)

ChromeDriver driver = new ChromeDriver();

In this case also, we will have only ChromeDriver class specific methods available. ChromeDriver inherits from ChromiumDriver and hence, methods like get(String url), findElement(By locator), findElements(By locator), manage(), close(), quit() etc. will be available to the driver object reference.

And obviously, cross browser testing will not be possible.

4. RemoteWebDriver and ChromeDriver top casting :

RemoteWebDriver driver = new ChromeDriver();

RemoteWebDriver is the concrete class that has implementations of all WebDriver and WebElement interface declared methods. It is a valid top casting.

Here, we have a RemoteWebDriver type reference variable, which can be referenced to a FirefoxDriver or EdgeDriver class object if needed. As it is a parent class, it is not limited to specific browser driver object types as in case of ChromiumDriver type reference. (in points 2 and 3)

5. WebDriver and ChromeDriver top casting :

WebDriver driver1 = new RemoteWebDriver("remoteAddress",capabilities);
WebDriver driver2 = new ChromeDriver();

WebDriver interface is the grand parent interface to ChromeDriver class. As ChromeDriver is already inheriting from RemoteWebDriver class, all implemented methods will be available to the ChromeDriver object.

Also, we have a WebDriver type reference variable, which can be referenced to a FirefoxDriver or EdgeDriver class objects if needed.

The first driver reference driver1 will launch the browser on a remote machine.

Conclusion :

All the above top castings are valid of course. It’s not like there will be any compiler error or runtime exceptions. But all of them won’t be useful to our requirements, as they shouldn’t. The hierarchy is designed to be used in a certain way.

Please feel free to provide any arguments or inputs in the comments.

Happy learning!