Blog Post

We use Selenium WebDriver to automate web application testing. Selenium videos directly talks with browsers by using browsers native support.

It really is actually easy than the Selenium RC once you start using it. You just need to set up your project, after you have set it, Selenium training acts like a normal library.

Selenium WebDriver Training Architecture is easily understood if you break it into parts and after that learn it. So here we will break up the Structure into three components :

Language Level Bindings
WebDriver API

In the very first box you'll be able to see that we have mentioned a number of the programming languages under Bindings, using these languages we can make a framework.

Using all these language amount bindings we can execute selenium WebDriver code. Once we make the framework using all these programming languages, it will help interact with the selenium WebDriver and then can work on different browsers.

Now the bindings whatever we take and produce a framework, conveys with WebDriver API. The WebDriver API interprets the command taken from Bindings and transfers it to the respective Driver.

In short you can declare the WebDriver API has a common library which sends commands to individual Drivers.

Now the Driver interprets the commands send by the WebDriver API on the specific browser. And once the command is executed the result is sent back through the API to you where you can see the result on your own system where you have written the code.

So now to comprehend the entire process is actually simple. For example you are using Java, which means that your java binding will socialize with the selenium WebDriver videos API and then the WebDriver API is having a whole library of commands, so it sends commands to the various browsers.

The Drivers then execute the commands at real browser and sends the effect through the WebDriver API to your system where you have written the code and then you can actually see the result.

For instance, you have written your code in Java. So your java code(Binding Code) will issue some commands through the selenium WebDriver. The WebDriver wire protocol can interpret those commands of binding code.

The Driver server keeps on waiting for all these commands, after it gets the commands it interprets those commands and automates the browser and then throws back the result through the WebDriver API to the code and you'll be able to view the consequence.

We can synchronize the internet driver in two ways :

1. Explicit wait : For explicit wait we must make use of thread.sleep().

Disadvantage in explicit wait

Each and every time when there is need to match speed of the application and speed of test execution we need to use thread.sleep().

For example : In case the program needs to be synchronized for 10 times ( 10 times pages are getting loaded), we must make use of thread.sleep() statement for 10 times.

sleep() will await the whole time that's established even in the event the page is loaded or not.
Ex : If specified time is 60 seconds, but page loads within 10 seconds, the statement waits for another 50 seconds.

2. Implicit wait :

The command for implied wait is :

driver.handle().timeout().implicitWait(arg1, arg2);

In arg1, establish the time that needs to be waited in number. Ex: 30, 40 , 60

In arg2, set whether the arg1 should wait for seconds or minutes or days etc. ex: TimeUnit.SECONDS

If we use implied wait, we need not use each time if the pages are becoming loaded, rather use only once in the whole script. Consistently once in the whole script, use in the beginning of script.

The implicit wait WOn't await the whole time that's specified, rather it will only wait, until the entire page is laoded. When page is loaded, it's going to perform next measure.

For instance, in the event the specified time is 50 seconds and if the page gets loaded within 5 seconds, the implicit delay isn't going to wait for another 45 seconds, instead it is going to come out of the wait loop and execute next step.

Selenium RC:

Due to the Same Origin Policy limitation in selenium core, the examiner had to install the web server on their local systems as well as the whole program under evaluation.

ThoughtWorks had another genius Paul Hammant , who created a server which acted as HTTP proxy and was successfully able to fool the browser that the program under test and selenium core come from the exact same domain name. It was named as Selenium Remote Control or Selenium 1.

Disadvantage of Selenium RC : Selenium RC solved the problem of Selenium Center but Selenium RC is slow as third party is involved.

Selenium Grid:

Now the challenge was to reduce the execution time as much as possible. Patrick Lightbody developed Selenium Grid which successfully minimized the test execution time . Initially it was named as Hosted QA.

Selenium WebDriver :

Selenium RC was slow in test execution, thus came selenium Webdriver. Here no evaluation reports were becoming generated but it was quicker. To create the report , TestNG can be used.

Webdriver is an interface which includes abstract method that are needed to automate a web application. These subjective methods are implemented in comparable browser classses.

If we need to work with Firefox browser, we need to make use of its own corresponding type.

Note: We cant create an item for interface.

We need to make an item of Firefox class. Upcast it to WebDriver. Using WebDriver you can use any programming language to create your test scripts.

The programming languages which can be utilized for scripting using WebDriver are : Java, .Net, Python, Perl, Php, Ruby etc.

Posted Mar 30, 2016 at 9:28pm



Posts (3)

Signup for PureVolume, or Login.