Selenium webdriver architecture

It is very important to know how webdriver tool works and how it is designed. This will helps to take the good advantage of the tool at the same time it will helps to make right automation framework.

Following figure shows the architecture of selenium webdriver.

Selenium webdriver architecture mainly consist of three components

1. Language level bindings
2. Selenium webdriver API
3. Drivers

1) Language Level Bindings :

         At the Left hand side of the above figure, there are some bindings and these are language level bindings and with the help of that you can implement the Selenium webdriver code. 

          In simple words they interact with the Selenium webdriver and work on various browsers. So we have a common API that we use for Selenium that has a common set of commands and we have various bindings for the different languages. 

           So you can see there’s Java, Java, Python, Ruby, there’s also some other bindings and new bindings can be added very easily.

2) Selenium webdriver API:

        Now these bindings communicate with Selenium webdriver API and and this API send the commands taken from language level bindings interpret it and sent it to respective driver. 

         Basically it contains set of common library which allow to send command to respective drivers.

3) Drivers:

       On right hand side of the figure, you see we have various internet browser specific drivers such as IE driver, a Firefox, Chrome, and other drivers such as HTML unit which is an interesting one. 

       It works in headless mode which make test execution faster. The basic idea here is that each one of these drivers knows how to drive the browser that it corresponds to.

How exactly it works?

Let say you have written test using java (binding code) against Selenium API and that binding code is going to issue commands across webdriver wire protocol. 

This is a rest-based web service that is able to interpret those commands. The driver server is just a little executable that runs each one of the drivers has this driver server that basically listens on a port on your local machine when you run your tests and it’s waiting for these commands to come in. 

When these commands come in it interprets those commands and then automates the browser and then returns those results back.

<-- Previous || Next -->