Selenium WebDriver 101

Let’s start by quickly understanding what WebDriver is.

Selenium is one of the most popular web-automation tools. Surprisingly, a lot of people actually get confused about what Selenium really is.

Here is the official version of what Selenium is:?https://www.selenium.dev/documentation/en/

WebDriver?is the?core of Selenium. It is an interface that uses browser automation APIs provided by browser vendors to simulate user behaviour and interaction by controlling the browser in the form of running tests.

WebDriver drives a browser either locally or on a remote machine using the Selenium server. Selenium WebDriver refers to both the language bindings and the implementations of the individual browser controlling code. This is commonly referred to as just?WebDriver.

The Selenium Browser Automation Project?also lists a quick example of how to quickly get started with using WebDriver.

Below is another example of how this code can look like:

var webdriver = require('selenium-webdriver'), test = require('selenium-webdriver/testing'), assert = require('assert');test.describe("Google Search", function() { test.it("should take user input correctly", function() { var driver = new webdriver.Builder(). withCapabilities(webdriver.Capabilities.chrome()).build(); driver.manage().timeouts().implicitlyWait(1000); driver.get("https://localhost:8082/community-app"); var element = driver.findElement(webdriver.By.id("uid")); element.sendKeys("mifos"); var value = element.getAttribute("value"); value.then(function(value) { assert.equal(value, "mifos"); }); });});

Why do we need a Test Automation Framework?

As seen in the above example, it is easy to get started using WebDriver to simulate user behavior.

However, typically, one uses WebDriver to automate many different user scenarios / interactions in order to get quick validation if the functionality in the product-under-test is working correctly, as expected. Some of these products may have a small-life, however, most of these would be around for a long time.

As a result, the team testing this product would have a lot of user scenarios that they would want to be automated. I have seen cases where the team has 1000s of tests identified and automated for their product-under-test.

In such cases, continuing to implement tests in similar ways as shown in the simple, getting-started example will quickly turn into a nightmare for various reasons of code quality, maintainability, extensibility and scalability.

You may set up some structure for your tests, and build some sort of a framework, but that will still be limiting as you scale.

In the above example, of test implementation in Ruby, the home_page.rb file ended up being 1000+ line long, which made it very difficult to quickly understand what this class ended up doing, and what functionality was implemented here.

The architecture of such a framework looks as simple as this, which could also be referred to as non-existent: