UI Automated Testing 

UI or User Interface is THE most important aspect of your product. A product can use the best hardware resources and business logic, but it is the UI that delivers the data to the end-user, and the end-user has to like the presentation of data.

Also, UI is not just about looks and feel. It is also about how functional it is, regarding the usage, transition, loading time and caching of data.

The UI also has to be elegant, just enough to traverse through the data meaningfully but not too complex as to spook the end user.

To represent data, the UI has different components, each associated with one or more events. The events may be to trigger some other component in the UI like pop-ups or modal boxes, interact with the server, change the DOM, trigger some animation effect, transition to a different page and so on.

The end-user needs everything to work just the way it’s supposed to, no surprises anywhere, for them to be mentally invested in your product. Hence, the UI has to be tested thoroughly before it is released to mitigate any bugs or issues that might come up.

What is UI testing?

UI testing is testing every functionality that the user is likely to do, can do but should not be able to, plus checking if the interaction with the server happens within the acceptable time frame. The UI testing ensures what is expected to work, what is expected to fail and when.

Consider some test cases like

1. Add a new row to a grid, enter all the field values, does the app save the data?
2. Submit done, before all the fields are entered, does the app allow them to continue? 
3. Clicks cancel, does the app discards all the entered data?
4. End date before the start date, does the app allow this? 
5. Correct values after some calculation?
6. From a menu? Does the correct form open?
7. From a menu, does the app show valid options?

All these, and many more of such scenarios have to be considered and tested on to give the end-user a smooth app experience.

Why Automate UI testing?

So here’s where we start, testing the UI. 

In the good old days, the companies used to hire people for the sole purpose of testing the UI. These people, or testers, were given a set of scenarios where the UI could malfunction, and it was their job to methodically torpedo the UI and report the test cases where malfunction happened.

However, this is a costly operation in terms of man-hours and is not scalable. As the application got bigger, there would arise the need to retest the part/all of the application repeatedly. New dependencies would get added, some functionalities may change, larger amounts of data would require more complex components and so on. The performance of some components might also be time-sensitive.

Due to all these reasons, the Manual testing of UI started getting unreliable and inadequate to test the UI.

Hence, the genesis of Automated UI testing.

What is UI automated testing?

So back to the original question, what is UI Automation testing? UI automation testing is similar to manual testing. But instead of having a user go through the app and visually verify the behavior, you create a script for each test case. Script a series of actions and verify the data values, properties etc.

There are many tools for testing the UI. In this article, we will discuss Selenium. 

Selenium

Selenium is an umbrella project for a range of tools and libraries that enable and support the automation of web browsers.

It provides extensions to emulate user interaction with browsers. Testing scripts in Selenium can be written using the following languages : Java, Python, C sharp, Ruby, Javascript and Kotlin.

Writing basic automated testing script using selenium in Java:

1. chrome driver – ChromeDriver is a separate executable that Selenium WebDriver uses to control Chrome. It is maintained by the Chromium team and open source contributors.

To download chromedriver, visit here.

2. Selenium WebDriver – In WebDriver, test scripts can be developed using any of the supported programming languages and can be run directly in most modern web browsers.

Selenium WebDriver API provides communication facility between languages and browsers.

Basically, through the WebDriver, Selenium converts the test script actions into corresponding browser ready code which is invoked when any user interacts with the browser manually. This conversion or compilation takes place through the browser drivers. 

Browsers supported by Selenium WebDriver: Internet Explorer, Mozilla Firefox, Google Chrome, Safari

Note: Each browser has its own specific driver

Some benefits of selenium WebDriver are: Multiple Browser Support, Multiple Languages Support, Speed, Simple Commands 

Getting started with Selenium in Java

The code style and structure of testing UI with Selenium in Java is similar to that of JUnit or TestNG. 

To use selenium with java, please follow the instructions from this page.

Problem statement: Go to google.com and search for “Sachin Tendulkar”

import org.openqa.selenium.*;

public class SeleniumDemo{
Public static void main(String argos[]){
WebDriver webDriver;
System.setProperty("webdriver.chrome.driver", "/path/to/webdriver");

webDriver = new WebDriver();
webDriver.navigate().to("https://www.google.com");

webElement searchBox = webDriver.findElement(By.xpath("xpath/of/the/element/from/DOM"));
searchBox.click();
searchBox.sendKeys("Sachin Tendulkar");
searchBox.submit();
    }
}

In this code snippet, the webDriver entity is initialized. Using the webDriver entity, we navigate to google.com (in this case). We get the pointers to the search box using the findElement function and XPath. Then using the searchBox entity, we just emulate human action of click, type text and submit.

Note: To get XPath of any DOM object, inspect element and hover over the element. Then, right click, copy and copy the full Xpath.

Design pattern – Page Object model 

Maintenance is easy for small scripts. As you add more and more lines to your code, things start getting real.

The issue with large scripts is that if 10 different scripts are using the same page element, with any change in that element, you need to change all 10 scripts. This is cumbersone and prone to error.

Instead of directly defining the objects for each of the DOM elements to be tested in a single page/script, we can define the objects and their associated functions in more than one file and import them in the test script.

A good way to organize all elements is defining them for each page in a separate Java class.

This class can be reused in all the scripts using that element. In future, if there is a change in the web element, we need to make the change in just 1 class file and not 10 different scripts.

An example is shown below.

HomePage.java

Import org.openqa.selenium.*;
Import org.openqa.selenium.support.*;

Public class HomePage{

@FindBy(xpath="/xpath/to/downloads")
Private webElement downloads;

Public HomePage(WebDriver webDriver){
  this.webDriver = webDriver;
  PageFactory.initElements(webDriver, this);
}

Public void downloads_OnClick(){downloads.click();}

}

HomePageTests.java

Public class HomePageTests{
WebDriver webDriver;
HomePage homePage;

@BeforeMethod
Public void setup(){

System.setProperty("webdriver.chrome.driver", "/path/to/webdriver");
webDriver = new ChromeDriver();

homePage = new HomePage(webDriver);
}

@AfterMethod
Public void cleanup(){webDriver.close();}

@Test
Public void downloads(){
webDriver.navigate().to("https://www.selenium.dev/downloads/");
homePage.downloads_OnClick();
}
}

Here, we created a HomePage class for the homepage of selenium website and imported it to be used in test script.

Similarly, you can also create a page for Downloads, Documentation, About etc.

Selenium – Level 2 

Selenium has different page loading strategies : Normal, Eager, None

It is one of the many options which can be applied to the WebDriver before executing the actions.

Most of the web applications get data asynchronously using AJAX or equivalent library. When a page is loaded by the browser the elements may load at different times.

Hence, it becomes difficult to identify the element. Also, the script may wrongly throw a ElementNotVisibleException, which is not justified as it was supposed to be loaded asynchronously or dynamically at a different time. 

Some examples of these cases are pop-ups, Modal Box and dynamic loading of data through AJAX. To solve this issue of time delays between DOM objects, Selenium has the feature of emulating time delays through Implicit, Explicit and Fluent wait.

Implicit wait – It sets the web driver to wait for a certain amount of time before it throws an exception. 

Explicit wait – It configures the WebDriver to wait for certain conditions or maximum time exceeded before throwing an exception. It gives better options than implicit wait as it waits for dynamically loaded Ajax elements. 

The main benefit of Explicit wait is that it is applied to only some page elements which are expected to show a time delay or behavior different from the rest of the elements.

The sample code for implicit and explicit wait is shown below:

import org.openqa.selenium.*;

public class SeleniumDemo{
Public static void main(String argos[]){
WebDriver webDriver;
System.setProperty("webdriver.chrome.driver", "/path/to/webdriver");

webDriver = new WebDriver();

            // implicitly wait for each element to load for 10 sec               

            driver.manage().timeouts().implicitlyWait(10,TimeUnit.SECONDS) ;

webDriver.navigate().to("https://www.google.com");

            WebDriverWait wait = new WebDriverWait(driver, 20);

webElement searchBox = webDriver.findElement();

            // Wait for 20 sec for the search box to load

            searchBox = wait.until(ExpectedConditions.visibilityOfElementLocated(By.xpath("xpath/of/the/element/from/DOM")));

searchBox.click();
searchBox.sendKeys("Sachin Tendulkar");
searchBox.submit();
    }
}

driver.manage().timeouts().implicitlyWait(10,TimeUnit.SECONDS) ;

In the above code, Implicit wait will accept 2 parameters, an integer and the time measurement which can be SECONDS, MINUTES etc.

WebDriverWait wait = new WebDriverWait(webDriver, 20);

searchBox = wait.until(ExpectedConditions.visibilityOfElementLocated(By.xpath("xpath/of/the/element/from/DOM")));

In the above code, WebDriverWait object will take 2 parameters: the web driver and time frame. Using the static function visibilityOfElementLocated from ExpectedConditions class will explicitly wait for the search box to load on the web page.

So, this was a brief article about Selenium, its internal architecture, and different features provided by it to automate UI testing.

Almost all of the UI testing can be automated by the concepts and code pieces described above.

Also Read: Building Software For Legacy Systems