DEV Community: Faisalkhatri123

Automating Flutter Apps Using Appium Flutter Driver With Java

Faisalkhatri123 — Mon, 12 Feb 2024 14:45:06 +0000

Mobile users worldwide have been constantly increasing over the recent years. Mobile applications have enabled the delivery of daily-use goods to luxury commodities at the customers’ doorstep.

As per Statista, mobile app downloads increased to 255 billion in 2022, up by more than 80 percent from 140.7 billion app downloads in 2016. Users downloaded almost 77 billion mobile applications worldwide during the first half of 2023.

The growing demand for mobile applications necessitates continuous development of robust frameworks that enable quick and adaptable mobile app creation, keeping pace with rapidly evolving business needs.

There are many native mobile application development frameworks, like React Native, Ionic, Xamarin, Swift, etc., that are popular and trending in the market. Flutter is the latest addition to these frameworks that support building cross-platform application development. As shown below, Flutter has gained immense popularity compared to other cross-platform mobile app testing frameworks available in the market!

Learn why Python is the top choice for automation testing. This comprehensive tutorial provides a step-by-step guide to Python automation testing to help you streamline your testing process.

Source

For faster feedback on the build quality, it is recommended to perform automation testing as it can provide accurate results on executing the same tests multiple times.

In this Appium testing tutorial, we will learn to test the Flutter mobile application using the Appium Flutter Driver with Java. We will also deep dive into installing Flutter, using Inspector, and writing mobile automation tests using Appium.

What is Flutter?

Flutter is Google’s cross-platform open-source mobile development framework for developing Android and iOS applications using a single code base. Introduced in May 2017, it is a comprehensive framework encompassing widgets, a rendering engine, testing and integration tools, and APIs. This all-inclusive framework empowers developers to build and deploy mobile applications effortlessly.

Since its launch, it has proven to be a great cross-platform framework that can be used to develop high-quality applications that look like native Android and iOS apps. Examples of applications built using Flutter include Google, Alibaba, and many others.

Flutter is a convenient toolkit that is easy for creating animations and high-quality UI components. It has 250.9K followers over X (earlier Twitter), 160K Stars on GitHub, and 124K followers on Reddit. When writing this blog, the latest version of Flutter is 3.16.

Different types of mobile applications

There are three different types of mobile applications:

Native mobile app
Mobile web app
Hybrid mobile app

What are native mobile applications?

Native mobile applications are developed specifically for the phone’s operating system. Almost 98% of the phones run on either Android or iOS. These applications are installed on the device and store the data on it. These applications have access to essential phone peripherals like cameras, GPS, microphones, and more.

While developing native Android applications, developers commonly use languages like Kotlin or Java, while the development of iOS applications typically involves languages such as Swift and Objective-C. Some native mobile applications include the Calculator app, Google Maps, and popular games like Pokémon GO.

Test your native app and website on real iOS and Android devices hosted on the cloud. LambdaTest is a convenient, cost-effective and centralised solution for running realtime mobile testing platform with real devices cloud.

What are mobile web applications?

Mobile web applications are web applications that are optimized for mobile screen(s). They are websites written in HTML/CSS, run by a browser, and aren’t mobile applications.

These applications don’t need to be downloaded and installed on the phone. It can access a limited amount of the device’s native features and information like geolocation, media, etc. Examples of mobile web applications include the Uber app and shopping websites like amazon.com. These websites can run on the mobile browser and perform all the functions like a mobile application.

What are hybrid mobile applications?

Hybrid applications combine elements of both Native and Web applications. The core application is built using web technologies like HTML, CSS, and JavaScript and then wrapped within a native application.

The app is run within a native application and its embedded browser rather than being shown using a mobile browser. An Android application uses the WebView element to display the app, while the iOS application uses the WKWebView for the same function.

In short, Hybrid Mobile app = Native app + Mobile Web app. Examples of Hybrid applications include Facebook, Twitter, LinkedIn and Instagram.

Testing Flutter applications v/s Native applications

Assessing native applications is straightforward, thanks to the availability of tools and frameworks designed for conducting unit testing on these applications.

The Espresso framework by Android can be used to test native Android applications. Similarly, the XCTest framework can be used to test iOS applications. Over and above these frameworks, other mobile app testing tools like WebdriverIO and Appium are popular and used for testing mobile applications thoroughly. Recently, Appium released a 2.0 version with more advanced features, making it a more robust framework.

For testing the Flutter app, the flutter_driver that comes pre-installed with Flutter SDK can be used to write automated tests. However, the problem in using flutter_driver is that the test engineer should be well versed in Dart programming language to write tests using flutter_driver.

Flutter applications can be automated using the Appium Flutter Driver, developed by the Appium community. With the Appium Flutter Driver, there is no need to get exposure to the Dart programming language. The automation tests of the Flutter application can be written in Java, JavaScript, Python, etc., the languages supported by the Appium framework.

To automate any mobile application, we need to locate the selectors that can be used to locate the mobile elements on the application and interact with them. The Appium Inspector tool cannot be used to find the Flutter application’s selectors.

The Flutter Widget Inspector tool can visualize and explore Flutter widget trees and help understand the existing layouts. We will also require help from developers and ask them to add the respective locators in the application so that they can be used in the automated tests to interact easily with the mobile elements.

The following is a summarized list that shows the difference between testing the Native and Flutter applications:

Let’s dive deep into how to perform automated Flutter testing using the Appium Flutter Driver with Java.

Getting started with Flutter

As we learned in the earlier section of this blog on using Appium Flutter Driver with Java, Appium Inspector cannot inspect and locate the Flutter application’s mobile elements. Hence, we need a Flutter Widget Inspector for it.

In this section, we will learn about downloading and installing Flutter SDK. Next, we will check out a Flutter sample app and update the required settings in Android Studio. Finally, we will run the Flutter app on the Android emulator and check out the Flutter Widget Inspector.

We need access to the Flutter application’s code base for running the Flutter Widget Inspector. The following steps will help us install Flutter on the local machine.

Downloading and Installing Flutter SDK

You can download Flutter SDK from Flutter’s official website for Windows, macOS, Linux, and ChromeOS platforms.

I am currently using macOS, so I will be clicking on the macOS box and navigating to the download page for further installation steps on macOS.

On the macOS installation details page, I will select and download the Apple Silicon zip file, as I currently use the Macbook Pro with an M2 chip. Another zip file for Macs with Intel chips can also be used.

Once the zip file is downloaded, we must perform the following steps to install Flutter SDK on the local machine:

Extract the downloaded zip file.
Setting the Environment variable for Flutter.
Run Flutter Doctor.

Explore the Top 17 Programming for Automation testing Languages in 2024.

Cloning the Flutter sample mobile app

With the help of the following command, the Flutter sample repository can be cloned.

git clone git@github.com:flutter/samples.git

Opening the Flutter sample application in Android Studio

The Provider Shopper sample Flutter application will be used for test automation.

Open the project in the Android Studio app after the successful cloning of the sample project repository is complete.

Adding the Flutter plugin to Android Studio

The Flutter plugin needs to be added to Android Studio as it helps compile and run the Flutter app. The Flutter plugin can be installed using the Android Studio >> Settings >> Plugins menu.

Setting the Flutter SDK path in Android Studio

Note: The Flutter SDK includes the full Dart SDK and has the Dart command-line interface in its bin folder.

Once Flutter SDK is configured, Dart SDK will be auto-configured.

Updating the dev dependencies in the pubspec.yml file

The dev_dependencies for flutter_test, test, and flutter_driver need to be added in the pubspec.yml file.

dev_dependencies:
 test: any
 flutter_test:
   sdk: flutter
 flutter_driver:
   sdk: flutter

The below screenshot of the pubspec.yml file shows the additions of dev_dependencies.

Filename: pubspec.yml

Importing the dev dependencies

The dev_dependencies updated in the pubspec.yml need to be imported, which can be done using the following command:

flutter pub get

Updating the main.dart file

The following import statement needs to be added to the main.dart file for importing flutter_driver_extension.

import 'package:flutter_driver/driver_extension.dart';

The enableFlutterDriverExtension() method should be added in the main() method before the runApp statement in the main.dart file.

void main() {
    enableFlutterDriverExtension();
    runApp(MyApp());
 }

Below is the screenshot of the main.dart file after adding the code mentioned above statements:

Starting the Flutter Android application on the Android emulator

The Flutter application can be run on the Android emulator by using the following steps:

Start the Android emulator.
Select the Android emulator name from the dropdown box, click the Play button to build the Provider Shopper application locally, and run it on the selected emulator.

How to test Android Flutter applications using Appium Flutter Driver?

The following are the details about the technical stack used in this blog to automate the Flutter application using Appium Flutter Driver with Java.

The first step in automating any mobile application is to locate the mobile elements to perform the interactions on it. In the case of Flutter applications, the Flutter Widget Inspector, which comes as an inbuilt tool with Flutter, will be used to inspect elements. The Appium Inspector is incapable of locating the Flutter mobile elements.

Test your native app and website on real iOS and Android devices hosted on the cloud. LambdaTest is a convenient, cost-effective and centralised solution for running realtime and Automated test on online real device testing.

What is Flutter Widget Inspector?

Within the Flutter framework, Widgets serve as the fundamental building blocks. They encompass form controls like textboxes and buttons and layouts like centering, padding, and rows.

Flutter widget trees can be explored and visualized using the Flutter Widget Inspector. It helps in understanding existing layouts and diagnosing the layout issues.

Flutter Widget Inspector

The Flutter Inspector is a tool that helps explore and visualize the Flutter widget trees. It can help locate the selectors for the mobile elements used in the mobile automation tests. It can also be used to understand the existing layouts and diagnose related issues.

How to use Flutter Widget Inspector?

Flutter Widget Inspector can only be started after the local build is created and the Flutter application runs in the Emulator/Simulator. To showcase the work of Flutter Widget Inspector, we will be running the local build on an Android emulator.

Flutter Widget Inspector can be started by clicking on the Flutter Inspector toolbar on the extreme right of the Android Studio screen.

The Flutter Widget Inspector should open as shown in the screenshot below:

We need to follow the below steps to locate the mobile elements:

Click on the Select Widget Mode button in Flutter Inspector.
Navigate to the Android emulator and select the field for which the mobile element needs to be located.

Let’s locate the mobile element for the Username field of the Provider Shopper app by clicking on the Select Widget Mode button and selecting the Username field in the app. It will locate the mobile element for the Username field, and as shown in the screenshot below, it shows the mobile element as “TextFormField”.

However, if you notice, there is no key attached to it. Hence, it will be challenging to locate this field as we can see other elements for which the same element, “TextFormField,” is shown.

Need to convert BCD codes to Decimal quickly? Our BCD to Decimal Converter tool provides an easy way to convert BCD codes to Decimal. Try it now and save time.

Let’s add a key to the Username field to make it unique so we can locate it easily.

To add a key, we need to minimize the Flutter Widget Inspector window; just below it, we will notice the login.dart file is already open. This file houses all the elements and their respective properties for the login page.

Let’s add the key for the Username field by adding the following line of code:

key: const Key("username"),

Save the login.dart file after adding the key for the Username field.

Halt the locally running app, restart it, and build it locally. Then, utilize the Flutter Widget Inspector to confirm the successful addition of the key by inspecting the Username field.

We can also see that the key value “username” is displayed next to the TextFormField for Username.

Congratulations! The key for the Username field is successfully added and can be used as a locator for locating this field in the automation tests.

Let’s repeat the same steps for the Password field and update its key.

Update Key for Password field

Password Key updated successfully can be viewed in Flutter Widget Inspector

Next, we need to locate the mobile element for the ENTER button to click on it to log in to the application.

We will follow the same steps as we did for the Username and Password fields, but we will not be updating the key for this button; as we can see, it already has the mobile element — TEXT– with the value “Enter”. This can be used in automated tests for interacting with this button.

To run the Android automation tests, we would require the apk file to be generated. As we use Appium Flutter Driver with Java to interact with the app and run the automation tests, we must compile the build in debug or profile mode as Appium Flutter Driver does not support the apps in release mode.

Decode UTF8 encoded data with ease using our online UTF8 Decode tool now and simplify your workflow! Decode your data quickly and accurately.

Generating the build for Android and iOS

The following commands can be used to generate the Flutter app build in debug and profile mode for Android and debug, profile, and simulator mode for iOS.

Please make sure that before you run the command for generating the build, the local instance, if running, should be stopped by pressing the red Stop button on the toolbar.

The following command should be executed in the terminal for generating the Android build in debug mode:

flutter build apk --debug

Once the build generation is finished, the build output path will be printed in the console.

Let’s navigate to the path printed in the console and copy the apk file generated so we can use it in our automation tests.

Writing the automated tests for the Flutter app

The following are the summarized steps we did in the previous part of the blog before we wrote the automated tests using Appium Flutter Driver with Java:

Configure the Flutter SDK.
Set up the Flutter app project in Android Studio.
Locate the mobile elements using Flutter Widget Inspector.
Generate the Android build.

Finally, we are in the last stage of this blog on using Appium Flutter Driver with Java, where we will be writing the automated tests for the Provider Shopper — a sample app by Flutter. We will run the tests on the Samsung Galaxy S21 5G Real Device on the LambdaTest cloud grid that has Android 13 installed on it.

LambdaTеst is an AI-powered tеst orchеstration and еxеcution platform that allows you to perform Flutter app tеsting on a rеal dеvicе cloud both manually and automatically using tеsting framеworks such as Appium, Espresso, and XCUITеst.

Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials on mobile app testing, Appium automation, automation testing, and more.

The following test scenario will be automated in the app.

Test Scenario:

Open the Provider Shopper sample app on the Samsung Galaxy S21 5G real device on LambdaTest Cloud grid
On the Login Page, enter Username and Password.
Click the ENTER button to log in to the app.
Check that the title “Catalog” is displayed on the next page after successful login.

Need to encode your text into UTF-8 format? Use our UTF-8 Encode tool to encode your text for seamless communication across all platforms and devices. Try it for free today.

Login Page of Provider Shopper app

Catalog Page of Provider Shopper app

Implementation [Test Scenario]

Before implementing the test scenarios, we must download and install the Appium Flutter Driver. It can be installed using the terminal with the following command:

 appium driver install --source=npm appium-flutter-driver

With the installation of Appium Flutter Driver, we are now ready to start writing the test automation scripts for the Provider Shopper Flutter app.

A Maven project needs to be created, and the dependencies for Appium, Appium Flutter Finder, and TestNG should be added to the pom.xml file.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>io.github.mfaisalkhatri</groupId>
    <artifactId>flutter-lambdatest-demo</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>flutter-lambdatest-demo</name>
    <url>http://maven.apache.org</url>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <appium-java-client-version>9.0.0</appium-java-client-version>
        <testng.version>7.8.0</testng.version>
        <appium-flutterfinder-java.version>1.0.1</appium-flutterfinder-java.version>
        <lombok-version>1.18.30</lombok-version>
        <maven.compiler.version>3.11.0</maven.compiler.version>
        <java.release.version>17</java.release.version>
        <maven.surefire.version>3.2.2</maven.surefire.version>
        <maven.source.encoding>UTF-8</maven.source.encoding>
        <suite-xml>testng.xml</suite-xml>
        <argLine>-Dfile.encoding=UTF-8 -Xdebug -Xnoagent</argLine>
    </properties>

    <dependencies>
        <!-- https://mvnrepository.com/artifact/io.appium/java-client -->
        <dependency>
            <groupId>io.appium</groupId>
            <artifactId>java-client</artifactId>
            <version>${appium-java-client-version}</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.testng/testng -->
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>${testng.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.github.ashwithpoojary98</groupId>
            <artifactId>appium_flutterfinder_java</artifactId>
            <version>${appium-flutterfinder-java.version}</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>${lombok-version}</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>${maven.compiler.version}</version>
                <configuration>
                    <release>${java.release.version}</release>
                    <encoding>${maven.source.encoding}</encoding>
                    <forceJavacCompilerUse>true</forceJavacCompilerUse>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>${maven.surefire.version}</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>test</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <useSystemClassLoader>false</useSystemClassLoader>
                    <properties>
                        <property>
                            <name>usedefaultlisteners</name>
                            <value>false</value>
                        </property>
                    </properties>
                    <suiteXmlFiles>
                        <suiteXmlFile>${suite-xml}</suiteXmlFile>
                    </suiteXmlFiles>
                    <argLine>${argLine}</argLine>
                </configuration>
            </plugin>
        </plugins>
    </build>


</project>

Once the dependencies are updated in the pom.xml it is the time now to start with the configuration of Android Driver and its respective capabilities so we could run the tests on the Android device successfully. For setting the Android Driver and its capabilities, AndroidDriverManager class is created.

@Builder
public class AndroidDriverManager {

    private static final ThreadLocal<AndroidDriver> DRIVER = new ThreadLocal<>();

    private String buildName;
    private String testName;
    private Platform platform;
    private String platformVersion;
    private String deviceName;
    private String app;
    private static final String LT_USERNAME = System.getProperty("LT_USERNAME");
    private static final String LT_ACCESS_KEY = System.getProperty("LT_ACCESS_KEY");
    private static final String GRID_URL = "@mobile-hub.lambdatest.com/wd/hub";


    public AndroidDriverManager createAndroidDriver() {
        try {
            setDriver(new AndroidDriver(new URL(format("https://{0}:{1}{2}", LT_USERNAME, LT_ACCESS_KEY, GRID_URL)), setCapabilities()));
            setupBrowserTimeouts();

        } catch (MalformedURLException e) {
            throw new Error("Error while creating Android Driver Session");
        }
        return this;
    }

    public AndroidDriver getAndroidDriver() {
        return AndroidDriverManager.DRIVER.get();
    }

    public void quitDriver() {
        if (null != DRIVER.get()) {
            getAndroidDriver().quit();
            DRIVER.remove();
        }
    }

    private HashMap<String, Object> ltOptions() {
        final var ltOptions = new HashMap<String, Object>();
        ltOptions.put("username", LT_USERNAME);
        ltOptions.put("accessKey", LT_ACCESS_KEY);
        ltOptions.put("platformName", platform);
        ltOptions.put("deviceName", deviceName);
        ltOptions.put("platformVersion", platformVersion);
        ltOptions.put("app", app);
        ltOptions.put("automationName", "Flutter");
        ltOptions.put("build", buildName);
        ltOptions.put("name", testName);
        ltOptions.put("w3c", true);
        ltOptions.put("isRealMobile", true);
        ltOptions.put("autoGrantPermissions", true);
        ltOptions.put("plugin", "java-testNG");
        ltOptions.put ("visual", true);
        ltOptions.put ("console", true);
        ltOptions.put ("devicelog", true);
        return ltOptions;
    }

    private DesiredCapabilities setCapabilities() {
        DesiredCapabilities capabilities = new DesiredCapabilities();
        capabilities.setCapability("lt:options", ltOptions());
        return capabilities;
    }
    private void setDriver(final AndroidDriver driver) {
        AndroidDriverManager.DRIVER.set(driver);
    }

    private void setupBrowserTimeouts() {
        getAndroidDriver().manage()
                .timeouts()
                .implicitlyWait(Duration.ofSeconds(20));
    }
}

In AndroidDriverManager class, the first method that we will be discussing is the createAndroidDriver() that will set the Android Driver and its capabilities.

Need to convert Hex to RGB values? Use our Hex color to RGB Converter tool to convert Hex colors to RGB values — it’s fast, free, and accurate. Try it now for hassle-free conversions.

The ThreadLocal class is used to instantiate the Android Driver instance. This ensures that each thread has its isolated instance of the Android Driver. This will help us run the tests in parallel smoothly. Next, the setDriver() method will set the Android Driver.

For running the tests on the LambdaTest cloud grid, we need to provide the LambdaTest Username, Access Key, and Grid URL along with the desired capabilities. The LambdaTest Username and Access Key will be supplied while running the tests as the respective values are taken using the System.getProperty method.

The LambdaTest Username and Access Key can be fetched from the Account Settings >> Password & Security screen after logging in to the LambdaTest website.

The setCapabilities() method sets the desired capabilities for running the test on the LambdaTest cloud grid.

A separate ltOptions() method has been created to allow us to set all the LambdaTest capabilities for running the test on real Android devices. We need to provide the capabilities for automationName with the value “Flutter”. This particular capability setting needs to be provided for Flutter apps only.

These capabilities can easily be found on the LambdaTest Capabilities Generator, which generates the code while you set the desired capabilities from the UI.

You may notice that there are variables set for the following values in the ltOptions() method:

LT_USERNAME
LT_ACCESS_KEY
Platform
Platform Version
Device Name
Test Name
Build Name
App URL

All these values will be set using the testng.xml file hence the respective variables have been set here. This allows us to keep the platform and device details dynamic in the code and manage it using the testng.xml to run the test on different platform and device combinations.

@builder annotation has been placed over the AndroidDriverManager class. It is an annotation from the Lombok library, and it will help set the platform, version, device, etc. details in builder pattern format.

Once the Android Driver and the desired capabilities are set. Next, we must find the mobile elements to interact with them and run the automation test.

Page Object Model (POM) is used in this project as it helps the code maintainability, readability, and reusability. Page Object Model implementation will create separate classes to maintain the Login and Catalog pages.

The LoginPage class will handle all the Page Objects of the Login page.

public class LoginPage {

    private final AppiumDriver driver;
    private final FlutterFinder finder;

    public LoginPage(final AppiumDriver driver) {
        this.driver = driver;
        this.finder = new FlutterFinder(driver);
    }

    private WebElement userNameField() {
        return this.finder.byValueKey("username");
    }

    private WebElement passwordField() {
        return this.finder.byValueKey("password");
    }

    private WebElement enterBtn() {
        return this.finder.byText("ENTER");
    }

    public CatalogPage performLogin(final String userName, final String password) {
        this.userNameField().sendKeys(userName);
        this.passwordField().sendKeys(password);
        this.enterBtn().click();
        return new CatalogPage(this.driver);

    }
}

The mobile elements for the Username and Password fields are returned by the userNameField() and passwordField() methods using the byValuKey() method of Appium Flutter Finder.

Need to decode an encoded URL? Our free online URL Decode tool can help to decode any encoded URL. Fast, simple, and reliable, Try it now.

Likewise, the mobile element for the ENTER button is returned by the enterBtn() method. The performLogin() method will help interact with the Username and Password fields by entering the respective values in the field and clicking the ENTER button to perform the login action.

An instance of the CatalogPage class is returned by the performLogin() method, as the app will move to the Catalog page after login.

The CatalogPage class will take care of all the Page Objects of the Catalog page.

public class CatalogPage {

    private final FlutterFinder finder;

    public CatalogPage(final AppiumDriver driver) {
        this.finder = new FlutterFinder(driver);
    }

    public String pageTitle() {
        return this.finder.byText("Catalog").getText();
    }

}

The title of the Catalog page will be located by the pageTitle() method using the byText() method of Appium Flutter Finder and will return its text in String format.

Setting up the Base Test

Now, verify the scenario discussed in the earlier section by writing the test. The first step is to create a BaseAndroidTest class that will initialize the Android Driver and set the respective desired capabilities to run the tests on real Android Device; finally, it will gracefully quit the driver after the tests are run.

public class BaseAndroidTest {

    protected AndroidDriverManager androidDriverManager;

    @Parameters({"buildName", "testName", "app", "platformName", "version", "device"})
    @BeforeClass(alwaysRun = true)
    public void setupTest(final String buildName, final String testName, @Optional("app") final String app, final Platform platform, final String platformVersion,
                          final String deviceName) {
            this.androidDriverManager = AndroidDriverManager.builder()
                    .buildName(buildName)
                    .testName(testName)
                    .app(app)
                    .platform(platform)
                    .platformVersion(platformVersion)
                    .deviceName(deviceName)
                    .build()
                    .createAndroidDriver();
    }

    @AfterClass(alwaysRun = true)
    public void tearDown() {
        this.androidDriverManager.quitDriver();
    }
}

The setupTest() method in the BaseAndroidTest class will run before any test is invoked. It will instantiate the AndroidDriverManager class and supply the build name, test name, application URL, platform name, platform version, and device name capabilities using the @Parameters annotation in TestNG from the testng.xml file and finally will create a new instance of the Android Driver using the createAndroidDriver() method.

Once all the tests are run, the tearDown() method will gracefully quit the driver.

Writing the Automation Test

Finally, in the last section of this blog on using Appium Flutter Driver with Java, we will write the test to verify the working of the Android Flutter application. As discussed in the earlier section of this blog, we need to verify the working of the Android Flutter application by performing login by entering Username and Password and clicking on the ENTER button.

Next, we must verify that the Catalog page is titled “Catalog.”

public class FlutterSampleAndroidAppTests extends BaseAndroidTest {


    @Test
    public void testProviderShopperApp() {
        final LoginPage loginPage = new LoginPage(this.androidDriverManager.getAndroidDriver());
        final CatalogPage catalogPage = loginPage.performLogin("faisal.k@user.com", "Pass1234");
        assertEquals(catalogPage.pageTitle(), "Catalog");
    }
}

FlutterSampleAndroidAppTests class that extends the BaseAndroidTests class, is created to write the Android automation tests. The BaseAndroidTests class is extended so we can inherit the instance of Android Driver from it.

The testProviderShopperApp() method performs all the actions to test the app. The LoginPage class is instantiated first and has the Android Driver instance passed as a Constructor parameter.

As the performLogin() method from the LoginPage class returns a new instance of the CatalogPage class, hence the following statement makes sense:

After the user logs in the app, the title of the Catalog page — “Catalog” is verified using the assertEquals() method of TestNG.

Test Execution using TestNG

The testng.xml file must be placed in the project’s root folder. The parameters test name, build name, platform name, platform version, device name, and App URL must be updated in the file.

This test will run on the LambdaTest cloud grid on Android 13 –Samsung Galaxy S21 5G real device.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="Lambda tests Mobile automation test suite"  >
    <test name="Android Flutter app - Provider Shopper Tests " enabled="false">
        <parameter name="buildName" value="Android Flutter app Build"/>
        <parameter name="testName" value="Provider shopper android app tests"/>
        <parameter name="app" value="lt://APP10160161171700638856308564"/>
        <parameter name="platformName" value="ANDROID"/>
        <parameter name="version" value="13.0"/>
        <parameter name="device" value="Galaxy S21 5G"/>
        <classes>
            <class name="io.github.mfaisalkhatri.tests.FlutterSampleAndroidAppTests">
                <methods>
                    <include name="testProviderShopperApp"/>
                </methods>
            </class>
        </classes>
    </test> <!-- Test -->
</suite> <!-- Suite -->

We need to add the following values to run the tests on the LambdaTest cloud grid –

LambdaTest Username
LambdaTest Access Key

These values can be passed using the Run Configuration window in the IDE as

-DLT_USERNAME = -DLT_ACCESSKEY=

To run the test using IntelliJ, right-click on the testng.xml file and select the option Run ‘../testng.xml’.

Below is the screenshot of the test run using IntelliJ.

All the test execution can be viewed on the LambdaTest Dashboard, which provides all the minute details about the test execution.

LambdaTest Dashboard

Details like Video recordings, Screenshots, Appium logs, Device logs, OS name, OS version, Duration of test execution, etc., can be viewed in the build details screen by clicking the test session link on the dashboard page.

If you are a developer or tester looking to elevate your Appium automation skills, you can opt for the Appium 101 certification by LambdaTest! This comprehensive certification program allows you to use your Appium skills, covering essential concepts and best practices to automate real-world scenarios.

Convert your URLs into a secure and easy-to-read format with our URL Encode tool. Make sharing links easier and secured. Simply input your URL and let us do the rest.

Summary

There are multiple options of test automation frameworks that can be used to automate the Native applications. Nevertheless, Flutter applications present some limitations in this context. When it comes to identifying mobile elements in Native applications, the Appium Inspector tool proves useful, eliminating the necessity of delving into the source code of the applications. However, the Appium Inspector tool is ineffective for Flutter applications, requiring direct access to the source code. In this scenario, the Flutter Widget Inspector becomes crucial for locating the Flutter mobile elements.

Comparatively, automating the native application is much easier as we don’t need to know the programming language in which the native application is built. However, for Flutter, the tester needs to have some basic understanding of Dart programming language to configure and set up the Flutter app project for compiling and generating the Android and iOS builds.

The existing Appium Drivers, like UIAutomator, etc., don’t come in handy for the Flutter application. We need to have the Appium Flutter Driver to automate the Flutter application. Similarly, a separate Appium Flutter Finder library is required to locate the mobile elements, as the existing Appium libraries don’t work with Flutter.

I hope this blog helps you write automated tests for the Android Flutter application by saving time.

Happy Testing!

assertTrue() in Java: A Complete Tutorial

Faisalkhatri123 — Tue, 23 Jan 2024 08:23:04 +0000

Assertions are an important part of the automation testing process, ensuring the software functions as anticipated. If it is not working as desired, the tests have to be marked as failure and need to be halted to make the necessary investigation for the failure.

An assertion statement helps to test the assumption about the test. When performing test automation, assertions help us automatically verify the tests’ output. In Selenium automation testing, we come across multiple scenarios where it is necessary to decide on the subsequent execution of the tests.

This is important in cases where the test result of the previous test execution is a failure. If the tests depend on each other, it is recommended to halt the execution at the exact failure step by using *Hard Assertion*s so the other dependent tests are skipped to save time.

Consider an example of an end-to-end testing journey of an eCommerce application where the product checkout from cart tests depends on the add product to cart tests. If the add product to cart tests fail, subsequent tests should not be executed as they will fail.

The test execution halts when the condition (part of the assertion) is unmet. Hence, when Selenium automation testing with TestNG is performed, assertions can help us understand the expected behavior of the application and allow us to check the quality of the software under test.

JUnit 5 is one of the popular testing frameworks used by many test automation projects to execute and run automation tests and perform assertions. It is a very good library with different functions to perform automation testing seamlessly.

In this JUnit tutorial, we will demonstrate performing assertions and check specific conditions. using the assertTrue() in Java.

Simplify your data export process with our efficient SQL to CSV Converter. Convert SQL queries to CSV format seamlessly and unlock data versatility. Try it now.

What are Assertions in test automation?

Assertions are the core concept of functional testing. In automated testing, it forms an integral part of the test and is used to derive the outcome of the test execution. The test passes if the test result confirms the assertion; otherwise, it will fail.

It brings many benefits to test automation, like providing accurate test results, speeding up the test process by performing the required checks automatically, and confirming the expected behavior of the software under test. It also helps you catch the bugs and errors in the software easily, thus aiding you in getting faster feedback on the builds.

Assertions are Boolean expressions confirming where the specified condition works and are considered passed per the application’s behavior. If the outcome condition is true, the test will pass; if the outcome is false, the test will fail.

Consider an example of a Login web page, where the test is to check the login functions properly. Here, we make an assertion condition that if the Logout button is displayed successfully after Login, the test is marked as passed. If the Logout button is not displayed after Login, the assertion will fail, marking the test as a failure.

Looking for an easy way to convert your HTML files to JADE? Try our free online HTML to JADE converter tool to convert your HTML files to JADE format in seconds.

There are two types of assertions in automated testing:

Hard Assertion
Soft Assertion

Hard Assertion

Hard assertions ensure that the test execution is stopped when the asserting condition is not met. The next steps or tests, if any, will only proceed if the asserting condition is evaluated to be true.

This helps in the automated pipeline as it turns red in case of test failures, and test execution is halted until the necessary fixes are made to the build.

Soft Assertion

With Soft assertions, the test execution is not stopped if the asserting condition is not met. Even after the assertion fails, the test execution will continue until it reaches the test’s end. After the tests are executed, all the respective failures will be displayed in the logs.

Soft assertions should be used when the tests are not dependent on each other and passing one test condition does not impact the upcoming tests.

Having learned about the two types of assertions, Let us quickly move towards learning the assertTrue() in Java for performing assertions in the automated tests.

Tired of manually creating JSON data? Generate random JSON data in seconds with our easy-to-use tool. Try it now and make your development process a breeze.

What is the assertTrue() in Java?

assertTrue() method is available in the “org.junit.Assertions” class in JUnit 5. The Assertions class in JUnit 5 is a collection of utility methods supporting asserting test conditions.

It verifies the supplied condition and checks if it is True. Following are the two overloaded assertTrue() methods provided by JUnit 5:

assertTrue(boolean condition)

In this method, the Boolean condition is supplied as a parameter. If the condition is true, the test passes or is marked as a failure.

Syntax

assertTrue(boolean condition, String message)

In this method, the Boolean condition is supplied as the first parameter, and the second parameter is the message text displayed in case the condition fails.

Syntax

In the next section, let’s learn how to use these methods in the test.

How to use the assertTrue() method in the test?

There are two ways to use the assertTrue() method in the test.

The first is using the Assertions class and then calling the assertTrue() in Java.

The second way is to directly import the static assertTrue() method in the test.

Need a quick placeholder image for your project? Use our online placeholder image generator tool that helps you generate customizable images for your projects.

Setting up the project

Let’s now delve into the test scenarios and check the actual working of the assertTrue() in Java. We will use the following tech stack to demonstrate and run the tests on the LambdaTest cloud grid.

LambdaTest is an AI-powered test orchestration and execution platform that lets you perform Selenium Java testing at scale on an online browser farm of 3000+ real web browsers and operating systems. You even run your automated test suites with Selenium in parallel and achieve faster software release cycles.

Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around automated testing, Selenium testing, Java automation testing, and more.

First, let’s create a Maven project and add the dependencies for Selenium WebDriver and JUnit 5 in the pom.xml file to set up the project.

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>io.github.mfaisalkhatri</groupId>
    <artifactId>junit-examples</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>junit-examples</name>
    <url>http://maven.apache.org</url>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <junit.version>5.10.0</junit.version>
        <selenium.version>4.12.1</selenium.version>
        <junit.platform.launcher.version>1.10.0</junit.platform.launcher.version>
<maven-surefire-plugin.version>3.1.2</maven-surefire-plugin.version>
    </properties>

    <dependencies>
        <!-- https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>${selenium.version}</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.junit.platform/junit-platform-launcher -->
        <dependency>
            <groupId>org.junit.platform</groupId>
            <artifactId>junit-platform-launcher</artifactId>
            <version>${junit.platform.launcher.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>${maven-surefire-plugin.version}</version>
                <configuration>
                    <includes>**/*Test*.java</includes>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

The project setup is complete, with the dependencies updated in the pom.xml, and we can now proceed to write the automated tests.

Want to generate random binary numbers? Our free online Random Binary Number Generator lets you generate random binary numbers quickly and easily. Try it now.

Test Scenarios

We will cover the following test scenarios as a part of the automation test to demo the working of the assertTrue() in Java.

LambdaTest’s Selenium Playground

Checkbox Demo Screen

Test Scenario 2

Open the LambdaTest’s Selenium Playground website.
Navigate to the Redirection page.
Using assertTrue(), verify that the page header is displayed on successfully loading the Redirection Page.

LambdaTest’s Selenium Playground

Redirection Page

Test Scenario 3

Open the LambdaTest’s Selenium Playground website.
Navigate to the Data List Filter page.
Search for a record by entering the Attendee name.
Using assertTrue(), verify that the data retrieved contains the Attendee name entered in the search box.

LambdaTest’s Selenium Playground

Data List Filter Screen

We will run the tests on the Chrome browser on the Windows 10 platform using the LambdaTest Cloud grid.

Need random dates? Our online Random Date Generator tool generates random dates for your projects. Choose a start and end date, and let our tool do the rest.

Implementation [Test Scenario 1]

In test scenario 1, we must open LambdaTest’s Selenium Playground website and navigate to the Checkbox Demo screen. We need to tick the Option 1 checkbox in the Disabled Checkbox Demo section and use the assertTrue() in Java to verify that it is ticked successfully. We will also check that the Option 3 checkbox is disabled using the assertTrue() method.

The following automated test method named checkboxDemoTest() is written in the SeleniumPlaygroundTests class that will help us achieve the automation of the test scenario:

Filename: SeleniumPlaygroundTests.java

 @Test
    public void checkboxDemoTest() {
        createDriver(Browsers.REMOTE_CHROME);
        final String website = "https://www.lambdatest.com/selenium-playground/";
        getDriver().get(website);

        final HomePage homePage = new HomePage();
        homePage.navigateToLink("Checkbox Demo");

        final var checkboxDemoPage = new CheckboxDemoPage();
        assertTrue(checkboxDemoPage.checkIfCheckboxOneIsTicked(), "Check box one is not ticked");
        assertTrue(checkboxDemoPage.checkIfCheckboxThreeIsDisabled());
    }

The first line of the method will create an instance of the Chrome browser in the LambdaTest Cloud grid. createDriver() method is a static method in the DriverManager class that will help us instantiate a new instance of WebDriver.

Filename: DriverManager.java

The browser’s name passed in the createDriver() method parameter will get started. The REMOTE_CHROME browser name will call the setupChromeInRemote() method.

This method will set all the desired capabilities and the configuration required for running the tests on the LambdaTest Cloud grid. These capabilities can be directly copied using the LambdaTest Capabilities Generator.

Once the driver session is created and the Chrome browser is started, the next line in the test will navigate the user to the LambdaTest Selenium Playground website.

On the website’s Homepage, the Checkbox Demo link will be clicked to navigate the user to the Checkbox Demo page.

The Page Object Model is used in this project as it helps test readability, reduces code duplication, and acts as an interface for the web page under test. The HomePage class houses the page objects for the Home Page of LambdaTest’s Selenium Playground website.

As the Homepage contains links to different website windows, a generic method has been created to search the links using the respective LinkText and then click on it to navigate to the required page.

Our HTML Minify is a perfect tool for anyone looking to optimize website’s speed. Minify your code and optimize website for faster loading times in few seconds.

Filename: HomePage.java

public class HomePage {

    public void navigateToLink (final String linkText) {
        getDriver ().findElement (By.linkText (linkText)).click ();
    }
}

The next step is to tick the Option 1 checkbox under the Disabled Checkbox Demo section and verify that it is ticked successfully using the assertTrue() in Java.

We will also provide a message in the assertTrue() method so that if the test fails, this text will be printed in the console for easy interpretation of the failure.

The page objects for the Checkbox page are updated in the CheckboxDemoPage class. The checkboxOne() method will return a WebElement for the Option 1 checkbox.

CSS Selectors are faster and simpler than XPath, allowing for a clearer method to locate web elements. We can use the CSS Selector “div:nth-child(2) > div:nth-child(1) > input[type=”checkbox”]” to locate the Option 1 checkbox.

The checkIfCheckboxOneIsTicked() method will tick the Option 1 checkbox and return the boolean value stating if the checkbox is selected.

Filename: CheckboxDemoPage.java

public class CheckboxDemoPage {

    public WebElement checkboxOne() {
        return getDriver().findElement(By.cssSelector("div:nth-child(2) > div:nth-child(1) > input[type=\"checkbox\"]"));
    }
    public WebElement checkboxThree() {
        return getDriver().findElement(By.cssSelector("div:nth-child(2) > div:nth-child(3) > input[type=\"checkbox\"]"));
    }

    public void tickCheckBoxOne () {
        checkboxOne().click();
    }

    public boolean checkIfCheckboxOneIsTicked() {
       tickCheckBoxOne();
        return this.checkboxOne().isSelected();
    }

    public boolean checkIfCheckboxThreeIsDisabled() {
        return !this.checkboxThree().isEnabled();
    }
}

The next assertion performed using the assertTrue() in Java is to check that the Option 3 checkbox is disabled.

The checkIfCheckboxThreeIsDisabled() method from the CheckboxPage class is used to check the disabled state of the checkbox.

The point to note here is that we are using the “!” while returning the output of the boolean condition from the checkIfCheckboxThreeIsDisabled() method that uses the isEnabled() method. So, ideally, it will check that the checkbox is disabled and return the output as true, else it will return false.

Need to convert hex to decimal? Our online Hex to Decimal Converter tool converts hexadecimal to decimal numbers quickly. Get your conversions done in no time.

Test Execution

The LambdaTest Username and Access Key must be provided for authentication to run tests successfully on the LambdaTest Cloud grid. These values can be updated in the Run Configuration window, which can be opened using the Modify Run Configuration option by clicking the Green Play button beside the test method name.

The LambdaTest Username and Access Key values can be copied from the Profile >> Account Settings >> Password and Security window.

In the Run Configuration window, update the values for the Username and Access Key as follows :

-DLT_USERNAME= < LambdaTest Username > -DLT_ACCESS_KEY=< LambdaTest_Access_Key >

Once the credentials are successfully updated in the configuration window, the tests can be executed by selecting Run Configuration from the dropdown in the top menu bar and clicking on the green button.

Screenshot of the test execution

All the test details can be viewed on the LambdaTest dashboard, including platform name, browser name, resolution, test execution logs, time taken to execute the tests, etc.

Struggling with messy Lua scripts? Our Lua Beautifier tool provides clean and structured formatting. Beautify your code and Improve readability today.

Implementation [Test Scenario 2]

In test scenario 2, we will navigate to the Redirection page on LambdaTest’s Selenium Playground website and verify that the page title is displayed using the assertTrue() in Java.

The steps for test scenario 2 will be automated using the redirectionPageTest() method created inside the SeleniumPlaygroundTests.java class.

Filename: SeleniumPlaygroundTests.java

 @Test
    public void redirectionPageTest() {
        createDriver(Browsers.REMOTE_CHROME);
        final String website = "https://www.lambdatest.com/selenium-playground/";
        getDriver().get(website);

        final HomePage homePage = new HomePage();
        homePage.navigateToLink("Redirection");

        final var redirectionPage = new RedirectionPage();
        assertTrue(redirectionPage.isPageTitleDisplayed());
    }

The initial 3 lines in the test are the same as we discussed in the test scenario 1 implementation. We will not discuss the configuration and setup for creating a WebDriver session and launching the Chrome browser.

Once the website is loaded on the browser, the Redirection page is navigated, and further interaction is taken to check that the title is displayed on the page.

public class RedirectionPage {

    public boolean isPageTitleDisplayed() {
        return getDriver().findElement(By.tagName("h1")).isDisplayed();
    }
}

The RedirectionPage class is created to update all the page objects related to the Redirection page. The isPageTitleDisplayed() method returns a boolean value using the Selenium WebDriver’s isDisplayed() method.

First, the Page title will be located, and then, using the isDisplayed() method, the verification will be done to check that it is displayed on the page. The assertTrue() method is finally used in the test to check the result of the boolean condition returned by the isPageTitleDisplayed() method.

Struggling with messy Python Formatter & Beautifier Online scripts? Our Python Formatter & Beautifier Online tool provides clean and structured formatting. Beautify your code and Improve readability today.

Test Execution

The steps followed while executing Test Scenario 1 for setting the LambdaTest Username and AccessKey to execute the tests on the LambdaTest Cloud grid. The same steps need to be followed while executing this test.

As we have already set the LambdaTest Username and AccessKey in the Configuration window, we can re-use the same window and just change the test method name to run this test.

Click the Run/Debug Configuration dropdown and select the Edit Configuration option.

Select the redirectionPageTest() method name in the configuration window by clicking on the three dots next to the Method name field. Leave the other settings/configurations as they are and click “Apply” and then the “OK” button to close the configuration window.

The tests can now be executed by clicking on the green button next to the Run/Debug configuration field.

Screenshot of the test execution

The test execution can be checked in the LambdaTest Build details windows after logging in to the LambdaTest website. This window provides granular details of the test execution that help know the test analytics and execution status.

Don’t let encoding IDNs slow you down. Save time and hassle with our IDN Encode free online tool to quickly and easily converts internationalized domain names. Try it now.

Implementation [Test Scenario 3]

In test scenario 3, we will navigate to the Data Filter List page on LambdaTest’s Selenium playground website to search for an attendee record by entering a name. Once the records are retrieved based on the filter according to the name provided, the record will be verified using the assertTrue() method by checking if the Attendee name in the record contains the name searched for.

The steps for test scenario 3 will be automated using the dataFilterPageTest() method that is updated inside the SeleniumPlaygroundTests.java class.

Filename: SeleniumPlaygroundTests.java

 @Test
    public void dataFilterPageTest() {
        createDriver(Browsers.REMOTE_CHROME);
        final String website = "https://www.lambdatest.com/selenium-playground/";
        getDriver().get(website);

        final HomePage homePage = new HomePage();
        homePage.navigateToLink("Data List Filter");

        final var dataListFilterPage = new DataListFilterPage();
        final String attendeeName = "Dwayne";
        dataListFilterPage.searchAttendees(attendeeName);
        assertTrue(dataListFilterPage.getAttendeeName().contains(attendeeName));
    }

In this test, we will first open the Chrome browser in the LambdaTest Cloud grid and navigate to the Data List Filter Page on LambdaTest’s Selenium Playground website.

Next, it will search for the data with the attendee name “Dwayne”. Once the data is loaded on the page, the assertTrue() method will check the condition that the attendee name in the results contains the text — “Dwayne”. The test will be marked as pass if the text is found in the Attendee’s name in the data results.

Test Execution

The test for scenario 3 can be easily run by just changing the method name from the Run Configuration window, as shown in the screenshot below.

Once the method is selected, click the Apply button and then the OK button to close the config window. To run the test, click the Green Play button on the toolbar on the top,

Screenshot of the test execution

Simplify the process of converting JSON to YAML with our online JSON to YAML converter tool to convert JSON files to YAML. No sign-up required. Get started now.

Conclusion

Without assertions, an automated test is incomplete. Assertions help us to derive the results of the automated tests. This can help in providing faster feedback on the software builds.

assertTrue() in Java is used to perform assertions in automated tests. We can verify a boolean condition using this method. This web automation method can ideally be used to check if a particular web element, like a checkbox or a radio button is enabled. It can also help in checking if a particular text is displayed. Further, it can be used for checking boolean conditions like text on a web page containing a particular string or text.

I hope this helps you in writing better assertions for the automated tests.

Happy Testing!

assertTrue() in Java: A Complete Tutorial

Faisalkhatri123 — Tue, 16 Jan 2024 07:53:47 +0000

In this JUnit tutorial, we will demonstrate performing assertions and check specific conditions. using the assertTrue() in Java.

Get your CSS validated by our CSS Validator and eliminate syntax errors and other issues that could affect your website’s performance. Ensure your CSS code is error-free today.

What are Assertions in test automation?

There are two types of assertions in automated testing:

Hard Assertion
Soft Assertion

Hard Assertion

This helps in the automated pipeline as it turns red in case of test failures, and test execution is halted until the necessary fixes are made to the build.

Don’t let CSV errors slow you down. Validate and lint your CSV data with ease using our free online CSV Validator tool. Get accurate and error-free results in seconds.

Soft Assertion

Soft assertions should be used when the tests are not dependent on each other and passing one test condition does not impact the upcoming tests.

Having learned about the two types of assertions, Let us quickly move towards learning the assertTrue() in Java for performing assertions in the automated tests.

What is the assertTrue() in Java?

assertTrue() method is available in the “org.junit.Assertions” class in JUnit 5. The Assertions class in JUnit 5 is a collection of utility methods supporting asserting test conditions.

It verifies the supplied condition and checks if it is True. Following are the two overloaded assertTrue() methods provided by JUnit 5:

assertTrue(boolean condition)

In this method, the Boolean condition is supplied as a parameter. If the condition is true, the test passes or is marked as a failure.

Syntax

assertTrue(boolean condition, String message)

In this method, the Boolean condition is supplied as the first parameter, and the second parameter is the message text displayed in case the condition fails.

Syntax

In the next section, let’s learn how to use these methods in the test.

Minify your JS code without changing its functionality with our easy-to-use JavaScript Minifier that reduces the size of your scripts and improve website speed.

How to use the assertTrue() method in the test?

There are two ways to use the assertTrue() method in the test.

The first is using the Assertions class and then calling the assertTrue() in Java.

The second way is to directly import the static assertTrue() method in the test.

Setting up the project

Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around automated testing, Selenium testing, Java automation testing, and more.

First, let’s create a Maven project and add the dependencies for Selenium WebDriver and JUnit 5 in the pom.xml file to set up the project.

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>io.github.mfaisalkhatri</groupId>
    <artifactId>junit-examples</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>junit-examples</name>
    <url>http://maven.apache.org</url>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <junit.version>5.10.0</junit.version>
        <selenium.version>4.12.1</selenium.version>
        <junit.platform.launcher.version>1.10.0</junit.platform.launcher.version>
<maven-surefire-plugin.version>3.1.2</maven-surefire-plugin.version>
    </properties>

    <dependencies>
        <!-- https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>${selenium.version}</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.junit.platform/junit-platform-launcher -->
        <dependency>
            <groupId>org.junit.platform</groupId>
            <artifactId>junit-platform-launcher</artifactId>
            <version>${junit.platform.launcher.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>${maven-surefire-plugin.version}</version>
                <configuration>
                    <includes>**/*Test*.java</includes>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

The project setup is complete, with the dependencies updated in the pom.xml, and we can now proceed to write the automated tests.

Test Scenarios

We will cover the following test scenarios as a part of the automation test to demo the working of the assertTrue() in Java.

Test Scenario 1

Open the LambdaTest’s Selenium Playground website.
Navigate to the Checkbox Demo screen.
In the Disabled Checkbox Demo section, tick Option 1.
Using assertTrue(), verify that the Option 1 checkbox is ticked successfully.
Next, using assertTrue(), verify that the Option 3 checkbox is disabled.

LambdaTest’s Selenium Playground

Checkbox Demo Screen

Test Scenario 2

Open the LambdaTest’s Selenium Playground website.
Navigate to the Redirection page.
Using assertTrue(), verify that the page header is displayed on successfully loading the Redirection Page.

LambdaTest’s Selenium Playground

Redirection Page

Test Scenario 3

Open the LambdaTest’s Selenium Playground website.
Navigate to the Data List Filter page.
Search for a record by entering the Attendee name.
Using assertTrue(), verify that the data retrieved contains the Attendee name entered in the search box.

LambdaTest’s Selenium Playground

Data List Filter Screen

We will run the tests on the Chrome browser on the Windows 10 platform using the LambdaTest Cloud grid.

Transform your messy CSS code into beautiful and organized code with our user-friendly and efficient online free CSS Prettifier tool with just a few clicks.

Implementation [Test Scenario 1]

The following automated test method named checkboxDemoTest() is written in the SeleniumPlaygroundTests class that will help us achieve the automation of the test scenario:

Filename: SeleniumPlaygroundTests.java

 @Test
    public void checkboxDemoTest() {
        createDriver(Browsers.REMOTE_CHROME);
        final String website = "https://www.lambdatest.com/selenium-playground/";
        getDriver().get(website);

        final HomePage homePage = new HomePage();
        homePage.navigateToLink("Checkbox Demo");

        final var checkboxDemoPage = new CheckboxDemoPage();
        assertTrue(checkboxDemoPage.checkIfCheckboxOneIsTicked(), "Check box one is not ticked");
        assertTrue(checkboxDemoPage.checkIfCheckboxThreeIsDisabled());
    }

Filename: DriverManager.java

The browser’s name passed in the createDriver() method parameter will get started. The REMOTE_CHROME browser name will call the setupChromeInRemote() method.

Once the driver session is created and the Chrome browser is started, the next line in the test will navigate the user to the LambdaTest Selenium Playground website.

On the website’s Homepage, the Checkbox Demo link will be clicked to navigate the user to the Checkbox Demo page.

Filename: HomePage.java

public class HomePage {

    public void navigateToLink (final String linkText) {
        getDriver ().findElement (By.linkText (linkText)).click ();
    }
}

The next step is to tick the Option 1 checkbox under the Disabled Checkbox Demo section and verify that it is ticked successfully using the assertTrue() in Java.

We will also provide a message in the assertTrue() method so that if the test fails, this text will be printed in the console for easy interpretation of the failure.

The page objects for the Checkbox page are updated in the CheckboxDemoPage class. The checkboxOne() method will return a WebElement for the Option 1 checkbox.

The checkIfCheckboxOneIsTicked() method will tick the Option 1 checkbox and return the boolean value stating if the checkbox is selected.

Filename: CheckboxDemoPage.java

public class CheckboxDemoPage {

    public WebElement checkboxOne() {
        return getDriver().findElement(By.cssSelector("div:nth-child(2) > div:nth-child(1) > input[type=\"checkbox\"]"));
    }
    public WebElement checkboxThree() {
        return getDriver().findElement(By.cssSelector("div:nth-child(2) > div:nth-child(3) > input[type=\"checkbox\"]"));
    }

    public void tickCheckBoxOne () {
        checkboxOne().click();
    }

    public boolean checkIfCheckboxOneIsTicked() {
       tickCheckBoxOne();
        return this.checkboxOne().isSelected();
    }

    public boolean checkIfCheckboxThreeIsDisabled() {
        return !this.checkboxThree().isEnabled();
    }
}

The next assertion performed using the assertTrue() in Java is to check that the Option 3 checkbox is disabled.

The checkIfCheckboxThreeIsDisabled() method from the CheckboxPage class is used to check the disabled state of the checkbox.

Get faster loading times and better user experience with our efficient JSON minify tool. Quickly compress your JSON data with ease and optimize your website now.

Test Execution

The LambdaTest Username and Access Key values can be copied from the Profile >> Account Settings >> Password and Security window.

In the Run Configuration window, update the values for the Username and Access Key as follows :

-DLT_USERNAME= < LambdaTest Username > -DLT_ACCESS_KEY=< LambdaTest_Access_Key >

Screenshot of the test execution

All the test details can be viewed on the LambdaTest dashboard, including platform name, browser name, resolution, test execution logs, time taken to execute the tests, etc.

Don’t waste time debugging your YAML files. Use our free YAML validator tool to validate your YAML code quickly and identify syntax errors and fix them.

Implementation [Test Scenario 2]

In test scenario 2, we will navigate to the Redirection page on LambdaTest’s Selenium Playground website and verify that the page title is displayed using the assertTrue() in Java.

The steps for test scenario 2 will be automated using the redirectionPageTest() method created inside the SeleniumPlaygroundTests.java class.

Filename: SeleniumPlaygroundTests.java

 @Test
    public void redirectionPageTest() {
        createDriver(Browsers.REMOTE_CHROME);
        final String website = "https://www.lambdatest.com/selenium-playground/";
        getDriver().get(website);

        final HomePage homePage = new HomePage();
        homePage.navigateToLink("Redirection");

        final var redirectionPage = new RedirectionPage();
        assertTrue(redirectionPage.isPageTitleDisplayed());
    }

Once the website is loaded on the browser, the Redirection page is navigated, and further interaction is taken to check that the title is displayed on the page.

public class RedirectionPage {

    public boolean isPageTitleDisplayed() {
        return getDriver().findElement(By.tagName("h1")).isDisplayed();
    }
}

Test Execution

As we have already set the LambdaTest Username and AccessKey in the Configuration window, we can re-use the same window and just change the test method name to run this test.

Click the Run/Debug Configuration dropdown and select the Edit Configuration option.

The tests can now be executed by clicking on the green button next to the Run/Debug configuration field.

Screenshot of the test execution

Implementation [Test Scenario 3]

The steps for test scenario 3 will be automated using the dataFilterPageTest() method that is updated inside the SeleniumPlaygroundTests.java class.

Filename: SeleniumPlaygroundTests.java

 @Test
    public void dataFilterPageTest() {
        createDriver(Browsers.REMOTE_CHROME);
        final String website = "https://www.lambdatest.com/selenium-playground/";
        getDriver().get(website);

        final HomePage homePage = new HomePage();
        homePage.navigateToLink("Data List Filter");

        final var dataListFilterPage = new DataListFilterPage();
        final String attendeeName = "Dwayne";
        dataListFilterPage.searchAttendees(attendeeName);
        assertTrue(dataListFilterPage.getAttendeeName().contains(attendeeName));
    }

Test Execution

The test for scenario 3 can be easily run by just changing the method name from the Run Configuration window, as shown in the screenshot below.

Once the method is selected, click the Apply button and then the OK button to close the config window. To run the test, click the Green Play button on the toolbar on the top,

Screenshot of the test execution

Conclusion

Without assertions, an automated test is incomplete. Assertions help us to derive the results of the automated tests. This can help in providing faster feedback on the software builds.

I hope this helps you in writing better assertions for the automated tests.

Happy Testing!

How To Perform Visual Regression Testing With Selenium And Smart UI

Faisalkhatri123 — Tue, 21 Nov 2023 06:12:14 +0000

User Interface or UI is the most critical front-facing part of an application. If it is not good enough to capture the users’ attention, they may stop using the application. Currently, all businesses are operated online, and the basic need for operating an online business is to have a website or a mobile application that supports all the browsers, operating systems, and mobile devices that are popular in the region where the business is operated.

If the website or mobile application fails to captivate users, they may exit the site immediately after landing on the homepage. This phenomenon is often called the website’s bounce rate, indicating instances where visitors neither interact with content nor proceed to the second page.

As per the report, the average bounce rate is somewhere between 26% to 70%, with the optimal range between 26% to 40%. If the bounce rate is too high, it may affect the businesses, and the websites might not lead to conversion in sales.

Another report by Contentsquare says that users, after landing on the website, spent around 45 seconds to 54 seconds. This is less than a minute, and if the website behavior, responsiveness, and uniformity between the website pages are not good, users might leave the website without navigating to other pages.

Hence, monitoring the application’s User Interface(UI) and the User Experience(UX) is important. User experience(UX) refers to how easy the application is for the end user to learn and use.

Social Media websites such as Facebook, Instagram, Twitter, etc, do not come with an operating manual or a user guide. The UI and UX are so easy to understand that it appeals to the user to register themselves, login, and start using the application. Similarly, the same goes for shopping applications like Amazon. The UI makes it clear to the user that they can register, login, buy a product, or even cancel an order at their fingertips.

Though some applications have user guides, most are made in such a self-understanding fashion that users can learn to use them independently because the User Interface(UI) and User Experience(UX) make it so simple.

With every release of the applications, minor or major changes may be applied to existing User Interfaces, or new screens may also be added. With this, there is a need to check the application’s visuals after the recent changes have been applied by performing a round of regression tests on the User Interface(UI). It refers to checking the background color, text color, font, images, logo, etc are displayed correctly. The actual screen of the application can also be compared with the mock screens.

Test your native, hybrid, and web apps across all legacy and latest mobile operating systems on the most powerful Android emulator online.

Here is a screenshot of an image showing how the visual regression is performed as the product evolves.

In the baseline image, which is the initial version of the application, we can see that only the logo was displayed. In the next version, the logo and the text were designed to be displayed in the app. In the visual regression test, the difference was highlighted by comparing the latest image of the application with the baseline image.

In this blog on Selenium visual regression testing, we will discuss visual regression testing in detail and how to perform it with Selenium and LambdaTest’s SmartUI.

New to Selenium? Check our getting started guide — What is Selenium?

What is Visual Regression Testing?

Visual regression testing is a method to verify that the changes made to the User Interface(UI) of the application are correct so the users don’t face any difficulty interacting with it. It is a kind of regression testing. However, in this testing type, the User Interface of the application is closely tested and compared with the previous version.

Visual Validations such as location of the web elements, brightness, contrast, and color of the buttons, menus, components, text, and their respective alignments are verified in visual regression tests.

The target is to find visual bugs, such as misaligned buttons, overlapping images, texts, or buttons, partially visible elements, rendering issues, etc.

To make it understand better, let’s take a hypothetical example of a login screen of a demo application. Version 1 of the application had a simple login screen where the user could enter the Username and Password and click the Log In button to enter the website.

A comprehensive end-to-end Testing tutorial that covers what E2E Testing is, its importance, benefits, and how to perform it with real-time examples.

Login Page version 1

In Version 2 of the application, a new feature is introduced to allow users to sign in using their Google and Apple accounts. To accommodate this change, two new buttons were introduced on the Login page with Google and Apple account logos, allowing users to log in with the respective accounts.

Login Page version 2 [candidate for visual regression testing]

After the changes were implemented on Version 2 of the website, it can be seen that for accommodating the Google and Apple logos for allowing Login with the respective accounts, the Log In button was misaligned and started to overlap with the Password field.

This is a visual bug that can be caught using visual regression testing. This issue could occur across browsers, operating systems, and devices. It can be a huge turn-off and might irk the visitors to the website, and they may even stop using the website due to it.

As this is a simple example, Log In button overlapping with the Password field can be seen easily. However, imagine a Home Page screen of an eCommerce website. If changes happen on such a congested page with many web elements, texts, images, etc., it is hard to notice the issue manually.

Another example of the visual bug is the following screenshot from the Netflix website, where the visual bug surfaced that showed the placeholder instead of the phone number.

In such a situation, automated visual regression testing can come to the rescue and save our time as well as upkeep the quality of the application. Visual regression testing should be done for websites and mobile applications across different platforms, browsers, and mobile devices.

A comprehensive end-to-end Testing tutorial that covers what E2E Testing is, its importance, benefits, and how to perform it with real-time examples.

How does Visual Regression Testing work?

Visual regression testing is performed by pixel-by-pixel comparison of two application screenshots. The first one is taken with the stable version of the application.

For example, Version 1, which is the stable version of the application, this image is termed a “Baseline image.” The second screenshot is taken after the required changes are applied to the application. For example, Version 2, which is the current version under development, this image is called “Current Image.”

Both screenshots are compared by verifying that the web elements on the page are aligned correctly, not overlapping, and displayed in proper size and color. The text and fonts are also compared in visual regression tests.

The test is marked as successful if both of the comparisons of the screenshots show that there is no difference between them and the UI of the new version of the application is the same as it was in the previous version.

However, the test will fail if there is a difference in comparison between the images. The visual regression tool highlights the difference in Baseline v/s Current Image and shows the mismatch percentage.

Apart from showing the mismatch between the Baseline and Current image, visual regression testing also has many other important points to uncover. Let’s find out all of them in the next section of this blog on Selenium visual regression testing, where we discuss the importance of visual regression testing.

Why is Visual Regression Testing important?

An application can be useless if the UI and UX are not good and don’t support the application’s working. As per the Leadpages UX statistics, a good UI can raise a website’s conversion rate by 200%, whereas a 1-second delay in page response results in a 7% reduction in conversions.

Let’s take an example of an eCommerce web application, where the user can search for a product from the Home page and click the Add to Cart button to add the product to the cart. However, if the Add to Cart button overlaps and is misaligned with the Buy Now button and is not clickable, it would block the user from adding the product to the cart and eventually purchasing it.

Here, it has nothing to do with the functionality, as it will work once the user can add the product to the cart using the Add to Cart button. The problem is with the UI; the Add to Cart button is not displayed correctly.

The following screenshot shows the visual bug where the Add to Cart button is misaligned, and the user cannot interact. Also, it can be seen that the size of the Buttons is not as per the standard and needs to be fixed.

Screenshot of the web page after the visual bug was fixed

Functional testing mostly covers the verification and validation of data input and output. However, it doesn’t cover the visual issues like alignment of the buttons, text, background color contrast, etc. So, visual regression testing can help us uncover the UI issues here.

Visual regression testing is important in the following ways:

It helps provide a better User Interface and User Experience.
A good User Interface and User Experience builds trust and credibility.
It helps in identifying Cross-platform, Cross-browser, and Cross-devices issues.
A better UI and UX can serve as a guide to the user towards actions.
It helps verify what aspects of UI are being worked upon for the betterment of the business through websites/applications.

Considering the importance of visual regression testing, it is recommended to spend some effort on visual testing that might help in user retention.

Note: Visual Testing captures and verifies the visual appearance of an application or webpage to identify deviations from the expected design. On the other hand, Visual Regression Testing detects unintended visual changes between different versions of an application or webpage to prevent design regressions.

Let’s now move ahead and check out how to perform visual regression testing using Selenium WebDriver and LambdaTest’s Smart UI.

In this Appium Automation tutorial, learn about Appium and its benefits for mobile automation testing. Take a look at how Appium works and see how to perform Appium testing of your mobile applications.

How to run Visual Regression Tests with Selenium and LambdaTest’s Smart UI?

In visual regression testing, we compare screenshots and identify pixel variations. It is integrated with HyperExecute from LambdaTest, allowing you to execute Smart UI tests on the platform. We will use the following test scenario to demonstrate Selenium visual regression testing using Smart UI.

Test Scenario 1

Navigate to the LambdaTest’s eCommerce playground website’s Laptop product page
Set the Laptop product page image as the Baseline image using the automation code.
Navigate to the LambdaTest’s eCommerce website’s Desktop product page.
Compare the Desktop product page with the Laptop product page using visual regression on Smart UI.
Verify the differences in LambdaTest’s Smart UI.

Laptop product page — LambdaTest eCommerce website

Desktop product page — LambdaTest eCommerce website

Test Scenario 2

Navigate to the LambdaTest’s eCommerce playground website’s Tablets product page.
Set the Laptop product page image as the Baseline image in LambdaTest’s Smart UI.
Navigate to LambdaTest’s eCommerce website’s Home Page.
Compare the Homepage with the Tablets product page using LambdaTest’s Smart UI.
Verify the differences in the LambdaTest’s Smart UI.

Tablets product page — LambdaTest eCommerce website

Home Page — LambdaTest eCommerce website

Before implementing the test scenarios, let’s learn about setting up Selenium visual regression testing with Smart UI on the LambdaTest cloud grid.

Through this usability testing tutorial, you will learn how usability testing is a great way to discover unexpected bugs, find what is unnecessary or unused before going any further, and have unbiased opinions from an outsider.

Getting Started with Selenium Visual Regression Testing on Smart UI

To use Selenium visual regression testing on Smart UI, we first need to register with LambdaTest and access LambdaTest’s Smart UI.

Once we have access, log into the LambdaTest account, navigate to the Dashboard screen, and perform the following steps:

On the left-hand menu section, click the Smart UI menu.
In the Smart UI window, click the New Project button on the right-hand top corner of the screen.
Update the project details, as we will be performing the Selenium visual regression testing for the website, we need to select the platform as “Web”.
Visual regression testing can also be performed for mobile applications using real mobile devices and the Appium framework. Next, provide the project name.
Select your name in the Approver Name field, or if it’s your organization account and you need another person to be an approver, select the respective person’s account name in this box. Once all the details are updated, click the Create Project button to create the project successfully.
Next, select the framework you want to run your automation tests with. We will be selecting Selenium, Java, and TestNG here.
On selecting the framework, we will be taken to the next screen, where we will be provided with the screen to set the configurations. Ensure to provide the Smart UI Project Name capability in this screen, which is mandatory for Selenium visual regression testing. Once the capabilities are updated, we can copy it and use it in our automation test configuration.
Once the project is created successfully, it will be shown in the Smart UI project screen as shown in the screenshot below:

Setting the Baseline Image

After the Smart UI project is created successfully, we need to set the Baseline image, the visual regression will be performed by comparing the Baseline image with the current image of the application.

There are two ways to capture the Baseline image:

Uploading the Baseline image using Smart UI API.
Running the web automation test and setting the screenshot image captured in the first test as the Baseline image.

Uploading the Baseline image using Smart UI API

The following steps need to be performed to upload the Baseline image using API:

Step 1:

Navigate to the Smart UI Project screen and click on the project for which the Baseline image needs to be uploaded. Here, we will select the project we created in the previous section — “Visual_regression_web”.

Step 2:

On the next screen, click the Upload API button.

Step 3

In the next screen, Swagger will be displayed with the API details.

Click the Smart UI Automation tab.
Checkout for the Upload Screenshots API endpoint. This endpoint will be used to upload the Baseline image.
Copy the value provided in the after the words “PROJECT_TOKEN=” text. This will be required to upload the Baseline image.
Click the Try it out button to upload the image.

Step 4

After clicking the Try it out button, the following details must be provided in the API request to upload the Baseline image successfully.

FIELD NAME	DESCRIPTION
Files	We need to select the image file that needs to be set as a Baseline image in this field. Multiple files can also be selected here.
projectToken	This value is provided in the previous screen where we clicked on the Upload API button; we already copied this value previously that can be pasted in this field.
buildName	The name of the build for which you are running the tests. Any value can be provided here. It can be left as it is since it is an optional field.
Baseline	Select true in this field.
ScreenshotNames	Provide a name for the screenshot image.
githubURL	This is an optional field; it can be left blank. If needed, the GitHub URL for the project can be provided here.

Black Box testing? Don’t worry; we will be covering what is Black box testing, merits, demerits, types & techniques.

Step 5

Enter the Authorization details by clicking the Authorize button on the top right corner of the screen.

Step 6

Enter the LambdaTest credentials in the authorization details. The LambdaTest credentials are in the Profile >> Account Settings section.

In the Account Settings window, navigate to the Password and Security Tab and copy and paste the Username and Access Key values.

These values can be copied and pasted in the Authorization window. Click on the Authorize button and close the Authorization window.

Step 7

Click on the Execute button to upload the Baseline image.

On successful execution of the API request, we should get a response with status code 200 and status — “success” along with other details.

On successfully uploading the image through API, it should be reflected in the Smart UI project and marked as an Approved Baseline image.

We have successfully uploaded the Baseline image using the Smart UI API.

In this blog on the mobile app automation testing tools, we list the best 11 mobile automation testing tools with their advantages and business-friendly features.

Uploading Baseline Image using the Web Automation Tests

The other option to upload the Baseline image is to upload the image using the web automation tests; we will check out in the next section of this blog on Selenium visual regression testing after setting up the automation project with Selenium WebDriver.

Let’s first create and set up the web automation project. The following tech stack will be used to demo Selenium visual regression testing with Smart UI.

Programming Language — Java 17
Web Automation tool — Selenium WebDriver — version — 4.11.0
Visual Regression Testing tool — LambdaTest’s Smart UI
Application under test — LambdaTest eCommerce Playground
Build Tool — Maven
Test Runner — TestNG
Cloud Platform to run web automation tests — LambdaTest

Project Setup

Let’s create a Maven project and update the dependencies for the Selenium WebDriver and TestNG in the pom.xml file. Maven-compiler-plugin is updated in the build section of pom.xml to compile the sources of the project. The Maven-surefire-plugin is provided as it allows executing the tests in the project during the build lifecycle.

Following is the pom.xml file used in the project.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>io.github.mfaisalkhatri</groupId>
<artifactId>selenium-visual-regression-example</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>

<name>selenium-visual-regression-example</name>
<url>http://maven.apache.org</url>

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<selenium.java.version>4.11.0</selenium.java.version>
<testng.version>7.8.0</testng.version>
<maven.compiler.version>3.11.0</maven.compiler.version>
<surefire-version>3.1.2</surefire-version>
<java.release.version>17</java.release.version>
<maven.source.encoding>UTF-8</maven.source.encoding>
<suite-xml>testng.xml</suite-xml>
<argLine>-Dfile.encoding=UTF-8 -Xdebug -Xnoagent</argLine>
</properties>

<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium.java.version}</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.testng/testng -->
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>${testng.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.version}</version>
<configuration>
<release>${java.release.version}</release>
<encoding>${maven.source.encoding}</encoding>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire-version}</version>
<executions>
<execution>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
<properties>
<property>
<name>usedefaultlisteners</name>
<value>false</value>
</property>
</properties>
<suiteXmlFiles>
<suiteXmlFile>${suite-xml}</suiteXmlFile>
</suiteXmlFiles>
<argLine>${argLine}</argLine>
</configuration>
</plugin>
</plugins>
</build>
</project>

With the dependencies and plugins addition in the pom.xml file, the project setup is complete. Let’s now move ahead and learn how to perform Selenium visual regression testing with a practical scenario in the next section of this blog on Selenium visual regression testing.

Implementation [Test Scenario 1]

In this scenario, we will perform the visual regression for the LambdaTest eCommerce playground website’s Laptop product page by comparing it with the Desktop product page.

Before writing the tests and performing the image comparison using the visual regression Smart UI, we must configure the LambdaTest capabilities to run the test.

The LambdaTest Capabilities Generator helps us get all the required capabilities to run the test on the LambdaTest cloud grid.

LambdaTest is an AI-powered test orchestration and execution platform that lets you perform visual regression testing at scale using visual testing tools like Selenium. With the LambdaTest AI-driven Smart UI platform, you can run automated visual tests on an online Selenium grid across 3000+ browser environments.

If you wish to perform Selenium visual regression testing using LambdaTest SmartUI, visit the documentation — Selenium visual regression testing with Smart UI.

We also have a dedicated tutorial on visual regression testing with Smart UI. Watch it below!

Subscribe to our LambdaTest YouTube Channel for the latest updates on tutorials around Selenium, automation testing, and more.

Elevate the app testing process from these 12 best mobile app testing tools. Our comprehensive list includes top-performing tools for achieving excellence. Learn more here.

For running the visual regression tests using Smart UI, the following capabilities are required:

Smart UI Project Name — the values can be supplied using the key “smartUI.project” in the code.

Additionally, the following Smart UI options can be provided in the configuration to help perform Selenium visual regression testing using pixel-to-pixel comparison.

OPTION NAME	DESCRIPTION
largeImageThreshold	It will set the pixel granularity at the rate at which the pixel blocks are created.
errorType	It will show the differences in the output screen by identifying the pixel change type and capturing the intended view.
ignore	It removes the pixel-to-pixel false-positive rate in identifying the screenshot.
Transparency	It helps in adjusting test transparency settings and strikes a balance between highlighting and visual screening.
boundingBoxes: [box1, box2]	By specifying a bounding box measured in pixels from the top left, the comparison area can be narrowed down.
ignoredBoxes: [box1, box2]	By specifying a bounding box measured in pixels from the top left, a part of the image can be excluded from comparison

For more details about the options below, checkout the Advanced Test Settings options page.

This article on the Best UI Automated Testing Tools cover what is UI automated testing, challenges while performing UI testing, and top tools that can help you perform UI testing.

Setting the Baseline image

The Baseline image must be set first to perform the Selenium visual regression testing. We saw one way to update the Baseline image using the Smart UI API in the earlier section of this blog on Selenium visual regression testing. Let’s now learn about updating the Baseline image using the automation code.

Baseline image can be updated from the code using the following desired capability:

The values for the key “smartUI.project” is the name of the project we created in the Smart UI on the LambdaTest cloud grid.

The above capability is provided in the createChromeDriverInCloud() method in the DriverManager class.


public class DriverManager {

protected WebDriver driver;
private static final String LT_USERNAME = System.getProperty("LT_USERNAME");
private static final String LT_ACCESS_KEY = System.getProperty("LT_ACCESS_KEY");
private static final String GRID_URL = "@hub.lambdatest.com/wd/hub";

public void createChromeDriverInCloud() {
final ChromeOptions browserOptions = new ChromeOptions();
browserOptions.setPlatformName("Windows 10");
final HashMap<String, Object> ltOptions = new HashMap<>();
ltOptions.put("username", LT_USERNAME);
ltOptions.put("accessKey", LT_ACCESS_KEY);
ltOptions.put("resolution", "2560x1440");
ltOptions.put("video", true);
ltOptions.put("smartUI.project", "Visual Regression Selenium");
ltOptions.put("smartUI.baseline", true);
ltOptions.put("w3c", true);
ltOptions.put("plugin", "java-testNG");
final var smartOptions = new HashMap<String, Object> ();
smartOptions.put ("largeImageThreshold", 1200);
smartOptions.put ("transparency", 0.3);
smartOptions.put ("errorType", "movement");
ltOptions.put ("smartUI.options", smartOptions);
browserOptions.setCapability("LT:Options", ltOptions);
try {
this.driver = new RemoteWebDriver(new URL(format("https://{0}:{1}{2}", LT_USERNAME, LT_ACCESS_KEY, GRID_URL)), browserOptions);
} catch (final MalformedURLException e) {
throw new Error("RemoteDriver's URL not set correctly!");
}
this.driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
}

public WebDriver getDriver() {
return this.driver;
}

public void quitDriver() {
this.driver.quit();
}
}

The method createChromeDriverInCloud() sets the desired capabilities and options to run the web automation tests on the LambdaTest cloud grid.

createChromeDriverInCloud() also has the Smart UI options “largeImageThreshold”, “transparency”, and “errorType.” It is updated as follows:

Here is the full createChromeDriverInCloud() method for your ready reference:

With this, we have completed the configuration and setup of the project. Next, let’s discuss writing the tests.

Implementation

The ProductPage class has the checkVisual() method to help us perform the Selenium visual regression testing.

public class ProductPage {
private WebDriver driver;
public ProductPage(final WebDriver driver) {
this.driver= driver;
}
private static final String SCREEN_NAME = "Product-Page";

public void checkVisual() {
((JavascriptExecutor) this.driver).executeScript (MessageFormat.format ("smartui.takeScreenshot={0}", SCREEN_NAME));
}
}

The checkVisual() method will take a screenshot and update its name to “Product-Page”. This screenshot will be compared against the Baseline image.

Next, let’s write an automated test for Selenium visual regression testing.

public class VisualRegressionTests extends BaseTest {
@Test
public void testECommerceVisualRegression() {
this.driverManager.getDriver().get("https://ecommerce-playground.lambdatest.io/index.php?route=product/category&path=20");
final var productPage = new ProductPage(this.driverManager.getDriver());
productPage.checkVisual();
}
}

The VisualRegressionTests class is created for housing all the visual regression tests. For testing Test Scenario 1, the testECommerceVisualRegressionScenarioOne() method is created.

The following line of code will navigate to the Laptop Product page screen.

Next, the ProductPage class is instantiated, and its checkvisual() method is called, which will capture the screenshot of the Laptop product page.

The screenshot captured from this test will be uploaded in the LambdaTests’s Smart UI and marked as a Baseline image.

Next, we will rerun the test by changing the navigation URL and pointing it to the Desktop product page.

To summarize, the following is the current screenshot of the Laptop product Page

Deep dive to learn about Software automation testing, its uasage, types and also gain insights on how to get started with automated testing.

Test Execution:

The following testng.xml file is created in the project’s root folder. We will be executing this file to run the test.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="LambdaTest ecommerce playground website test suite ">
<test name="Visual Regression Tests">
<classes>
<class name="io.github.mfaisalkhatri.tests.VisualRegressionTests">
<methods>
<include name="testECommerceVisualRegressionScenarioOne"/>
</methods>
</class
</classes>
</test> <!-- Test -->
</suite> <!-- Suite -->

Run the test to upload the Baseline image by right-clicking on the testng.xml file and selecting the option ‘../Run ../testng.xml’

Screenshot of the test execution using IntelliJ:

Baseline image is set in the Smart UI testing platform on LambdaTest cloud grid after the test execution is complete.

The Baseline image is set, next, to run the comparison, we need to change the createChromeDriverInCloud() method in the DriverManager class by setting the “smartUI.baseline” capability to false.

The second change we require is to update the website URL so it navigates to the Desktop product page before it takes the screenshot.

Run the test again by right-clicking on the testng.xml file. Once this test is executed successfully, LambdaTests’s Smart UI will perform the visual regression and provide us with the results.

The following screenshot shows us the results of Selenium visual regression testing.

In the above screen, we can see the detailed view of the visual regression where the screenshots of the current image, Baseline image, and their respective difference is shown. We can also see that LambdaTest’s Smart UI provides us with the Mismatch percentage, i.e. 5.22%, by performing the pixel-to-pixel comparison.

The differences between the screenshots are highlighted in pink in the third image. We can Approve the build by clicking on the Approve Build button or Reject it using the Reject button displayed above the Mismatch %.

Learn why Python is the top choice for automation testing. This comprehensive tutorial provides a step-by-step guide to automation testing using python to help you streamline your testing process.

Implementation [Test Scenario 2]

In this scenario, we will perform the visual regression by changing the Baseline image to the Tablets product page and comparing it with the Home page of LambdaTest’s eCommerce playground Website. In this scenario, we will manually set the Baseline image using LambdaTest’s Smart UI.

The following is the screenshot of the Tablets product page.

The following is the Home page of the LambdaTest eCommerce website against which the Tablets product page will be compared in visual regression.

Writing the Tests

The test method testECommerceVisualRegressionScenarioTwo() is created in the VisualRegressionTests class

@Test
public void testECommerceVisualRegressionScenarioTwo() {
this.driverManager.getDriver().get("https://ecommerce-playground.lambdatest.io/index.php?route=product/category&path=57");
final var productPage = new ProductPage(this.driverManager.getDriver());
productPage.checkVisual();
}

The following line of code will navigate to the Tablets Product page screen.

Next, the ProductPage class is instantiated, and its checkvisual() method is called, which will capture the screenshot of the Tablet product page.

Test Execution

We will be executing this test twice. After the first execution of the test, we will set the Baseline image from the LambdaTest’s Smart UI. The visual regression comparison will be done on the second execution of the test.

The following testng.xml is created to execute the tests.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="LambdaTest ecommerce playground website test suite ">
<test name="Visual Regression Tests">
<classes>
<class name="io.github.mfaisalkhatri.tests.VisualRegressionTests">
<methods>
<include name="testECommerceVisualRegressionScenarioTwo"/>
</methods>
</class>
</classes>
</test> <!-- Test -->
</suite> <!-- Suite -->

Here is the screenshot of the test execution from IntelliJ:

After the test execution is complete, we should be able to see the screenshot uploaded to the Smart UI testing tool.

Click on the Make a Baseline button to update the current screenshot of the Tablets product page as a Baseline image for further visual regression tests.

Now, let’s return to the testECommerceVisualRegressionScenarioTwo() and update the URL to navigate the website’s Homepage.

Let’s execute the test using the same testng.xml file again and check the visual regression testing on the Smart UI.

After the test execution is complete, we should be able to see the screenshot uploaded to the LambdaTest’s Smart UI.

It can be seen in the image above the visual regression comparison shows a major difference of 67.06% between the Baseline image and the current image screenshots.

By running the above tests, it can be confirmed that visual regressions can help us catch the User Interface level bugs and correct them before it gets leaked into the production. It can also help in improving the overall User Experience.

In this Selenium JavaScript tutorial, as we deep dive into the basic concepts, explained the best practices and executed javascript for automation testing on cloud-based Selenium Grid.

Final Thoughts

Visual regression is the key to improving the overall User Experience and helps identify the UI-level issues. As we saw in the demonstration, it can highlight the granular differences by performing pixel-to-pixel comparisons. Thus making Software Developer’s and Software Tester’s lives easier.

In my experience, Selenium visual regression testing should be made a part of the Unit Test stage in the automated pipeline to get faster feedback on the User Interface, as it is the first thing that is seen by the end users. Faster feedback on the UI will help fix the issues early and help build the product’s quality.

How to Use @FindBy Annotation in Selenium Java

Faisalkhatri123 — Thu, 16 Nov 2023 06:36:38 +0000

Code maintenance and duplication are two common challenges that software teams often face, resulting in reduced performance and reliability. It also makes the code more complex, tightly coupled, and less flexible for refactoring. With all these problems, adding new lines of code to the software becomes quite tricky as we need to think of a logic to fit those lines within the code.

In automation test suites as well, we all face the same problem. The code becomes too complex and bulky. Even for adding a simple test for new functionality, we need to think twice and find a solution for checking which part of the code needs to be updated so it doesn’t hamper the existing working of the test suite. Sometimes, we have to repeat the same line of code multiple times because it is how the automation framework was designed to work.

Today, there are multiple automation test frameworks that help teams to automate tests and help in delivering quality software. Selenium WebDriver is a popular web automation framework that helps automate the tests for popular modern browsers like Google Chrome, Mozilla Firefox, Microsoft Edge, Safari, etc. To learn more about Selenium WebDriver, check out this guide on What is Selenium?

Writing automated tests using Selenium WebDriver is easy and simple. However, software testing teams face a bigger challenge: keeping the test implementation separate from the web page elements used in the tests.

Page Object Model, also called POM, is a popular design pattern in Selenium WebDriver that creates a page object repository to store WebElements separately in different classes to keep the tests clean and more readable.

Get your CSS validated by our CSS Validator and eliminate syntax errors and other issues that could affect your website’s performance. Ensure your CSS code is error-free today.

Design patterns help us overcome industry-standard approaches to solving a recurring problem and help us save time once we sensibly use the design pattern. Design patterns speed up development and are known to fix the problems before they are known in the implementation process. It also facilitates code maintenance, helps us avoid code duplication, and facilitates code readability.

Page Factory Model is another popular design pattern in Selenium. It is considered an Optimized Page Object Model that uses the PageFactory class in Selenium.

In this blog on using @FindBy annotation in Selenium, which is part of the Page Factory Model in Selenium WebDriver, we will also learn how to use @FindBys, @FindAll, and @CacheLookup annotations in Selenium Java.

What is Page Factory in Selenium WebDriver?

Page Factory is a way of implementing the Page Object Model that uses the PageFactory class. By using the PageFactory class in Selenium, testers can interact with web elements, making it robust with enhanced efficiency and simplicity in using Page Objects.

The following image shows the difference between the Page Object and Page Factory Model:

To use the Page Factory Model, we need annotations like @FindBy, @FindBys, and @FindAll for locating WebElement in the Page Object class. Next, we need to initialize the Page Object class using the initElements() method from the PageFactory class.

Protect your XML data with our online free XML Escape tool. Quickly escape your code and be assured from vulnerabilities with just a few clicks.

Let’s learn how to use the @FindBy, @FindBys, and @FindAll annotations to use the Page Factory Model efficiently.

Using @FindBy annotation in Selenium WebDriver

@FindBy annotation marks a field on the Page Object for locating the WebElement or a list of WebElements. It is used in coordination with the PageFactory class that allows users to easily and quickly create Page Objects.

There are two different implementation ways for using @FindBy annotation.

Using “How” and “Using” Strings
Passing Locator Strategy

Using “How” and “Using” Strings

The first way to implement @FindBy annotation is by using the “how” and “using” strings as parameters to the annotation by declaring a WebElement variable. The values in the parameter can be supplied as follows –

“how” — With the “how” enum in this parameter, you have the flexibility to utilize any of the following locator strategies:
ID
Name
ClassName
LinkText
PartialLinkTex
TagName
CSS
XPath
ID or Name
“using” — In this parameter, the actual selector needs to be supplied as per the locator strategy selected in the “how” parameter.

The syntax for using @FindBy annotation [Passing How enum]:

Demo: @FindBy using How enum

Let’s take an example of the Simple Form Demo screen on LambdaTest’s Selenium Playground website and locate the “Enter Message” field.

In this screen for the Enter Message field, we can use the ID locator — “user-message” as a selector to locate the field. So, to use it in the code with @FindBy annotation, we can write it as follows:

@FindBy(how = How.ID, using="user-message")
private WebElement enterMessageField;

Catch errors before they impact your JavaScript validator code. Our validator and linter enforces coding standards and helps you catch errors. Validate your code today.

Once we have defined the WebElement, we can directly use it in the methods to act on the element. The following lines of code show how to interact with the WebElement defined using @FindBy annotation:

public void enterMessage() {
this.enterMessageField.sendKeys("This is a test message");
}

However, to make this work, we need to initialize the initElements() method of the PageFactory class. intiElements() is a static method in the Page Factory class of Selenium that is used to initialize all web elements located by @FindBy annotation. It can be done in every Page Object class where we want to use the @FindBy annotation.

public SimpleFormPage(final WebDriver driver) {
this.driver = driver;
PageFactory.initElements(driver, this);
}

We will be initializing the initElements() method in the constructor of the SimpleFormPage class that holds all the page objects for the Simple Form page. Similarly, the initElements() method will have to be initialized in other Page Object classes as well.

Let’s now learn the other way of implementing @FindBy annotation.

Passing Locator Strategy

The second way to implement @FindBy annotation is to directly pass on the locator strategy and its respective selector as a parameter to the annotation by declaring a WebElement variable.

The syntax for using @FindBy annotation [passing locator strategy]:

Any locator strategy values can be passed in the parameter:

ID
Name
ClassName
LinkText
PartialLinkText
TagName
CSS
XPath

The above-mentioned locator strategy values are case-sensitive and must be used in small letters only.

Demo: @FindBy by directly passing the locator strategy

Let’s take an example of the Simple Form Demo screen on LambdaTest’s Selenium Playground website and locate the “Get Checked Value” button.

As per the DOM of the page, we can use the id — “showInput” as a selector for locating the Get Checked Value button. Let’s do this by using the @FindBy annotation and writing the following code:

@FindBy(id = "showInput")
private WebElement getCheckedValueBtn;

Similarly, we can use other locator strategies like name, CSS, XPath, etc.

Keep your JavaScript code safe from syntax errors with our free online JavaScript Escape tool by quickly and easily converting special characters in your JavaScript.

Once we have defined the WebElement variable for locating the WebElement using @FindBy, we can directly use it to perform interaction with the button.

public void clickButton() {
this.getCheckedValueBtn.click();
}

Don’t forget to initialize the intiElements() method from the PageFactory class to make the annotation work.

Using @FindBy annotation for finding multiple WebElements:

@FindBy annotation can also be used to return a list of WebElements if we want a list of elements to be returned using a single selector. We must define the variable that returns List<WebElement> using @FindBy annotation.

We can use either of the implementations as we discussed above for returning a list of WebElements using @FindBy.

The syntax for returning a list of WebElements using Implementation 1:

The syntax for returning a list of WebElements using locator strategy in @FindBy annotation:

For better understanding, let’s check out a practical implementation example for returning a list of WebElements.

Demo: @FindBy by directly passing locator strategy for finding multiple WebElements

Let’s take an example of the LambdaTest Selenium Playground website and check the total number of menu options on the main page.

There are a total of 37 menus displayed on this page. Let’s locate all these menus and return their list using a @FindBy annotation with the CSS Selector locator strategy in Selenium.

The CSS Selector “.container__selenium ul li a” can be used to return a list of WebElements for the menus. Let’s use this selector with @FindBy annotation.

@FindBy(css = ".container__selenium ul li a")
private List<WebElement> menus;

List of menus can also be returned using the How enum in @FindBy annotation as follows:

@FindBy(how = How.CSS, using =".container__selenium ul li a")
private List<WebElement> menus;

The following method will return the size of the list that can be used in the test to verify that the list has 37 items in it.

public int menuListSize () {
return this.menus.size();
}

Following is the Test to check the total number of menus in the menus list.

public class SeleniumPlaygroundTests extends BaseTest {

@Test
public void testMenus() {
this.driverManager.getDriver().get("https://www.lambdatest.com/selenium-playground/");
final var mainPage = new MainPage(this.driverManager.getDriver());
assertEquals(mainPage.menuListSize(), 37);
}

Following screenshot of the test execution from IntelliJ shows that the tests executed successfully.

Convert your JSON files to CSV format in seconds with our easy-to-use JSON to CSV Converter. It’s fast, reliable, and user-friendly, making data conversion simple.

This confirms that the list of menus has 37 items in it, and the @FindBy annotation we used to return a list of menu WebElements works perfectly fine.

This confirms that the list of menus has 37 items in it, and the @FindBy annotation we used to return a list of menu WebElements works perfectly fine.

Using @CacheLookup annotation in Selenium WebDriver

@CacheLookup annotation helps to cache the WebElement. When this annotation is applied over a WebElement, Selenium WebDriver keeps the cache of the WebElement instead of searching for it every time from the WebPage when the test is run. This helps in saving test execution time.

When to use @CacheLookup?

It is beneficial to use @CacheLookup annotation on the WebElements, which does not change when on the web page once it is loaded. The test speed and performance can be improved by using this annotation on the static elements on the web page.

When not to use @CacheLookup?

It is not recommended to use the @CacheLookup annotation for the WebElements that are dynamic and keep changing every time the page loads. Dynamic elements refer to the WebElement like Timer text that keeps changing every second. Another example would be a capital market website that shows the price of the stocks that keeps on changing every second or minute as per the stock trading. For such WebElements, if @CacheLookup annotation is used, we may get a Stale Element Exception.

The syntax for using @CacheLookup annotation:

From SQL to JSON in a snap! Convert SQL queries to JSON effortlessly with our SQL to JSON converter, enhancing compatibility and data interchange. Try it now.

Demo: @CacheLookup annotation

The following test scenario will be used to check out the working of the @CacheLookup annotation. We will run the test using the @CacheLookup annotation and run the same test by removing the @CacheLookup annotation. Next, we will check the performance by comparing the test execution time.

The following test scenario will be used to demo the working of @CacheLookup annotation, where the performance will be checked by running the tests after using @CacheLookup annotation over WebElements and removing them.

Test Scenario

Navigate to the Table Search Filter window on the LambdaTest’s Selenium Playground website.
Get the page header text and cache it using @CacheLookup annotation.
Perform assertion on the page’s header by getting its text.
Click on the Filter button and enter filter values for first name, username, and last name fields.
On retrieving the records, print the values of the first record on the console.
Perform the Test Execution and record the time after using @CacheLookup.
Remove the @CacheLookup annotation, rerun the tests, and check the time for test execution.

We will be using the @FindBy annotation, as we discussed in the earlier section, to locate the button and the fields.

The following class is created for housing all the WebElements on the Table Search page.

Filename: TableSearchPage

We will be caching every WebElement that we need to interact on this page. The following table shows the variable names used for the respective fields using the @FindBy annotation and @CacheLookup annotation to cache the WebElement.

FIELD NAME ON THE WEB PAGE	VARIABLE NAME IN THE TABLESEARCH CLASS FOR THE WEBELEMENT
Page Header	pageHeader
First Name field	firstNameField
Last Name field	lastNameField
User Name field	userNameField
Table Row retrieved after applying filter	tableRecord

Don’t let encoding IDNs slow you down. Save time and hassle with our IDN Encode free online tool to quickly and easily converts internationalized domain names. Try it now.

The pageHeaderText() method will return the text value of the page header that will be used in the test for assertion.

The searchForRecord() method will click on the Filter button and allow entering values in the Username, First Name, and Last Name fields.

Next, we need to get the text of the record that is fetched after applying the filter. The tableRecordValues() method will fetch the text of the record that will be retrieved after applying the filter values.

Let’s now move ahead and write the test where we will navigate to the Table Search page, perform the assertion for the page header text, retrieve the table record after applying a filter, and print the record fetched.

The testTableSearch() method is created for verifying the test scenario.

Filename: SeleniumPlaygroundTests

Note: I have declared two variables, startTime and endTime, to demo the test execution time in milliseconds.

Need to make your JSON code more readable? Our online JSON Prettifier tool makes your JSON data more human-readable. Copy, paste, and prettify in seconds.

Test Execution

We will be running the test twice and record the time taken to run the test. The first run will be using the @CacheLookup annotation, and the second will be without using the @CacheLookup annotation. This will help us compare the test execution time with and without cache.

Test Execution with @CacheLookup annotation

Here is the screenshot of the test execution using the testng.xml file with @CacheLookup annotation.

We can see that it took 481 milliseconds to run the tests.

Test Execution without @CacheLookup annotation

Before we execute the tests, let’s comment out all the @CacheLookup annotations in the TableSearchPage class.

Let’s execute the test again and check the time taken to execute the test.

It can be seen that it took 534 milliseconds to run the test. So, if we compare the time taken to run the test with and without using @CacheLookup annotation, it appears to be a difference of 53 milliseconds. As the test scenario was pretty straightforward, hence it is a steep difference here. However, if we take a complex scenario, it can be a major difference in seconds or minutes as well.

From this, we can conclude that using @CacheLookup annotation can save the test execution time, eventually helping us in quicker builds.

Minify your JS code without changing its functionality with our easy-to-use JavaScript Minifier that reduces the size of your scripts and improve website speed.

Using @FindBys annotation in Selenium WebDriver

@FindBys annotation is used to locate a WebElement or list of WebElements with more than one selector. The condition in using @FindBys is that all of the selectors given in the @FindBys should match the respective WebElement(s) criteria.

It is an “AND” condition between all the selectors given in the annotation. This is helpful in cases where we don’t have a unique locator for the WebElement that we need to interact with on the web page.

The syntax for using @FindBys annotation:

To implement @FindBys, we must pass on the multiple @FindBy statements as parameters and declare the WebElement or List< WebElement > variable.

It should be noted that @FindBy annotation can be used either by providing the How enum or by supplying the locator strategy directly. In the screenshot above, both ways have been shown to use the @FindBy while using the @FindBys annotation.

However, one more thing to note while using @FindBys annotations is that we need to provide the locators considering the parent-child relationship, using the attributes within the HTML tag won’t work with @FindBys annotation. The following example implementation will help in understanding in detail.

Implementation Example

Let’s take an example of the Radio button demo page on LambdaTest’s Selenium Playground website.

On this page, we will be locating the “Male” radio button by using the @FindBys annotation.

As we can see in the DOM, the class name “container” is the parent of the input tag with type, value, and name attributes for the Male radio button field. Similarly, if we check out the “Female” radio button, it also has the same hierarchy.

Even the name attribute is the same for both the radio buttons. The only difference in selector between Male and Female radio buttons is the value attribute, i.e., value=”Male” for Male radio button and value = “Female” for Female radio button.

As the locator is not unique here, we can follow the parent-child relation approach to locate the element by locating the parent first and then approaching to find the child element using the respective locators.

Transform your messy CSS code into beautiful and organized code with our user-friendly and efficient online free CSS Prettifier tool with just a few clicks.

The following lines of code will help us locate the Male radio button using the @FindBys annotation in Selenium:

@FindBys({
@FindBy(how = How.CLASS_NAME, using = "container"),
@FindBy(css = "input[value=\"Male\"]")
})
private WebElement maleRadioBtn;

Using the @FindBys annotation, first the parent WebElement with class name i.e. “container” is located and then the child element using the input tag with value attribute “Male” is used to finally locate the WebElement for Male radio button.

Similarly, @FindBys can locate multiple WebElements on the web page. The only change required is instead of WebElement we need to pass List<WebElement> as show in the image below:

Demo: @FindBys annotation

Let’s take an example of the Table Pagination demo page on LambdaTest’s Selenium Playground website. On this page, let’s locate the total number of columns in the table using the @FindBys annotation.

As we can see in the DOM, the parent WebElement for the table is its id — “table-id”. We can use it for locating the complete table. Now, to find the number of columns, it can be easily done by finding the column headers and returning their size.

The column headers of the table can be located using the CSS Selector — “thead > tr > th” Using @FindBys annotation, we can return list of WebElements for the column headers as follows:

@FindBy(how = How.ID, using = "table-id"),
@FindBy(css = "thead > tr > th")
})
private List<WebElement> tableColumns;

The above code will return a list of WebElements for table columns. We can use the size() method to get the number of columns and use it in the test to perform assertions.

Having learned about @FindBys annotation in detail, let’s check which exception is thrown by @FindBys annotation if the WebElement is not found.

Make your XML code easy to read and understand with our free online XML Prettify tool. Format your code for better readability and save time.

Using @FindAll annotation in Selenium WebDriver

@FindAll annotation is used to locate a WebElement or list of WebElements with more than one selector. While using @FindAll, it should be noted that either of the Selectors used should be matching to locate the respective WebElement(s).

It is an “OR” condition between all the selectors given in the annotation. @FindAll uses multiple @FindBy annotation statements in the parameter to locate the WebElements.

Using @FindAll, we can provide two or more different selectors for a WebElement, so in case the first locator doesn’t work, it will check the second. So, eventually, the idea is to make the test less flaky by providing more than one locator for a field that doesn’t have a unique locator.

The syntax for using @FindAll annotation:

@FindAll can be implemented by passing on multiple @FindBy statements in the annotation parameter and declaring the WebElement or the list of WebElements variables. Note that the @FindBy statement can be supplied using either of the two implementations, as we discussed in the earlier section of this blog. If you take a look at the syntax image, you will find that both of the implementation ways are shown with two @FindBy statements.

Demo: @FindAll annotation

Let’s take an example of the Ajax Form Submit Demo page on LambdaTest’s Selenium Playground website.

On this page, we will locate the Name field using two different locator strategies with @FindAll annotation.

In the DOM, we can see that two attributes can be used to locate the Name field, the first is using id — “title” and the second is using name — “title”.

The following lines of code will help us locate the Name field using the @FindAll annotation:


@FindAll({
@FindBy(id = "title"),
@FindBy(name = "title")
})
private WebElement nameField;

Using the @FindAll annotation id as well as name locator strategies are passed as a parameter with the @FindBy annotation. When the code is executed, it will first try to locate the nameField WebElement using the ID. If it is not found, it will try locating it using the Name strategy. The point to note here is that at least one criteria provided to locate the element should match.

Similarly, we can locate a list of WebElements using @FindAll annotation. The only change required will be the declaration. Instead of the WebElement, we must define it as List< WebElement >.

Here is the example code for returning a list of WebElements using @FindAll annotation from the Status Codes page of LambdaTest’s Selenium Playground Website.

The following code will help in returning the list of WebElements using @FindAll annotation

@FindAll({
@FindBy(how = How.CSS, using = "#__next > section.mt-50 > div > div > div > p"),
@FindBy(css = ".container .w-full > p")

})
private List<WebElement> statusCodeDetails;

We can make use of the size() method from the List interface to check for the number of elements present in the statusCodeDetails list.

public int getStatusCodes () {
return this.statusCodeDetails.size();
}

The getStatusCodes() method will return the total number of WebElements present in the statusCodeDetails list.

Tired of hard-to-read SQL code? Use our fast and reliable SQL Beautifier tool to format and beautify your SQL code, making it more structured and easy to read.

Which Exception is thrown if the WebElement is not found?

Navigating the intricacies of web element identification in test automation is vital for a robust and reliable testing framework. One aspect is understanding the exceptions that may arise when using annotations like @FindAll, @FindBy, and @FindBys. In this section, we delve into a specific question: what happens when the WebElement is not found using these annotations?

Let’s explore the exceptions that come into play when your automation testing script encounters this situation and how you can handle them effectively.

WebElement not found using @FindAll annotation

If the WebElement is not found using the @FindAll annotation, NoSuchElementException is thrown with appropriate logs.

Here is the screenshot of the NoSuchElementException thrown while searching for the incorrect selector for locating the Status Codes text on the Status Codes Demo page on LambdaTest’s Selenium Playground website.

In the logs, it can be seen that Selenium WebDriver tried finding the elements by using the @FindAll annotation.

WebElement not found using @FindBys annotation

NoSuchElementException is thrown with appropriate logs if the WebElement is not found using the @FindBys annotation.

Following is the screenshot of the NoSuchElementException thrown while searching for the incorrect selector for locating the Male radio button on the Radio button demo page.

In the logs, it can be seen that Selenium tried finding the elements by chaining the locators provided in the @FindBys annotation.

Need realistic sample data? Use our free online easy-to-use Random XML Generator to create custom XML data for testing and prototyping. No sign-up required.

WebElement not found using @FindBy annotation

If Selenium WebDriver cannot locate a WebElement using the @FindBy annotation, it throws NoSuchElementException. It details the selector for locating the element in the log that can help us investigate the failure.

Following is the screenshot of the NoSuchElementException that was thrown while searching for an incorrect selector provided:

Let’s move towards demonstration by automating a test scenario from LambdaTest’s eCommerce website using the @FindBy, @FindBys, and @FindAll annotations.

Demonstration: Locating elements and writing web automation tests

Before we get into writing the test automation scripts, let me share the details of the tools used to demo the test scenarios for using @FindBy, @FindBys, and @FindAll annotations.

Programming Language — Java 17
Web Automation tool — Selenium WebDriver — version — 4.11.0
Application under Test — LambdaTest’s eCommerce Playground website
Build Tool — Maven
Test Runner — TestNG
Cloud Platform to run web automation tests — LambdaTest

Project Setup

Let’s create a Maven project and update the dependencies for Selenium WebDriver and TestNG in the pom.xml. Simultaneously, update the maven-surefire and maven-compiler plugins in it.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>io.github.mfaisalkhatri</groupId>
<artifactId>selenium-pagefactory-demo</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>

<name>selenium-pagefactory-demo</name>
<url>http://maven.apache.org</url>

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<selenium.java.version>4.11.0</selenium.java.version>
<testng.version>7.8.0</testng.version>
<maven.compiler.version>3.11.0</maven.compiler.version>
<surefire-version>3.1.2</surefire-version>
<java.release.version>17</java.release.version>
<maven.source.encoding>UTF-8</maven.source.encoding>
<suite-xml>testng.xml</suite-xml>
</properties>

<dependencies>

<!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium.java.version}</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.testng/testng -->
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>${testng.version}</version>
<scope>test</scope>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.version}</version>
<configuration>
<release>${java.release.version}</release>
<encoding>${maven.source.encoding}</encoding>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire-version}</version>
<executions>
<execution>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
<properties>
<property>
<name>usedefaultlisteners</name>
<value>false</value>
</property>
</properties>
<suiteXmlFiles>
<suiteXmlFile>${suite-xml}</suiteXmlFile>
</suiteXmlFiles>
<argLine>${argLine}</argLine>
</configuration>
</plugin>
</plugins>
</build>
</project>

Test Scenario

Navigate to the Login Page of LambdaTest’s eCommerce Playground website.
Locate the E-Mail Address field using the @FindBys annotation.
Locate the Password field and Login using the @FindBy annotation.
Enter a valid email address and password in the respective fields.
Click on the Login button.
On successful login, verify that the My Account Page is displayed.
Locate the Logout link using @FindAll annotation and click on it to logout.

The login screen of LambdaTest’s eCommerce Website

Page displayed after successful Login with the Logout link

Implementation

Before we begin writing the code, let’s first find the selectors for the fields on the Login Page. The first field is the E-Mail Address field. Let’s check out the DOM of the web page to find the selectors for this field.

All the selectors for the Login Page fields will be declared in the LoginPage class.

We can see that the parent locator for this field is className = “card-body” and name attribute — “email” as well as ID attribute “input-email” can be used as the target locator. We will be using the @FindBys annotation to locate this field.

Need YAML data for testing? No need to stress about YAML data — Try our Random YAML Generator for a quick and effortless way to generate YAML data in seconds.

Below is the WebElement variable emailAddressField declared inside the LoginPage class.

@FindBys({
@FindBy(how = How.CLASS_NAME, using = "card-body"),
@FindBy(how = How.NAME, using = "email")
})
private WebElement emailAddressField;

Next, let’s locate the Password field.

In the DOM, it can be seen that locator strategies like ID — “input-password” and NAME — “password” can be used to locate the Password field.

Below is the WebElement variable passwordField declared inside the LoginPage class that will help locate the Password field.

@FindBy(how = How.NAME, using = "password" )
private WebElement passwordField;

Next, let’s locate the Login button.

It is pretty simple to locate the Login button, we can make use of CSS Selector — “input[type=”submit”].

Below is the WebElement variable loginBtn declared inside the LoginPage class to locate the Login button using the @FindBy annotation.

@FindBy (css = "input[type=\"submit\"]")
private WebElement loginBtn;

Let’s now create a new method named performLogin() inside the LoginPage class, that will perform the interaction with the E-Mail Address, Password fields, and Login button by entering the respective credentials in the fields to login in the website.

public MyAccountPage performLogin(final String emailAddress, final String password) {
this.emailAddressField.sendKeys(emailAddress);
this.passwordField.sendKeys(password);
this.loginBtn.click();

return new MyAccountPage(this.driver);
}

The performLogin() method consumes two parameters called emailAddress and Password that will be supplied from the test to perform login, and it will return a new instance of the MyAccountPage class. The new instance of the MyAccountPage class is returned from this method as, after success, the website will take us to the My Account Page.

We have declared the WebElement variables and a method to perform login. Now, it is time to use the initElements() method from the PageFactory class of Selenium so the annotations work seamlessly. We will call the initElement() method in the Constructor of the LoginPage class.

private final WebDriver driver;
public LoginPage(final WebDriver driver) {
this.driver = driver;
PageFactory.initElements(driver, this);
}

Below is the final version of the LoginPage class after all the variables, methods, and constructors are added to it.

public class LoginPage {
private final WebDriver driver;
public LoginPage(final WebDriver driver) {
this.driver = driver;
PageFactory.initElements(driver, this);
}

@FindBys({
@FindBy(how = How.CLASS_NAME, using = "card-body"),
@FindBy(how = How.NAME, using = "email")
})
private WebElement emailAddressField;
@FindBy(how = How.NAME, using = "password" )
private WebElement passwordField;

@FindBy (css = "input[type=\"submit\"]")
private WebElement loginBtn;

public MyAccountPage performLogin(final String emailAddress, final String password) {
this.emailAddressField.sendKeys(emailAddress);
this.passwordField.sendKeys(password);
this.loginBtn.click();

return new MyAccountPage(this.driver);
}
}

Once the login step is complete, the My Account page will be displayed. To verify this step, let’s locate the title of the page that is “My Account”.

We can make use of the CSS Selector — “#content > div:nth-child(1) h2” to locate the title — “My Account”.

The following myAccountTitle variable declared inside the MyAccountPage class will locate the title using the @FindBy annotation.

@FindBy(css = "#content > div:nth-child(1) h2")
@CacheLookup
private WebElement myAccountTitle;

@CacheLookup annotation is used for this variable to store this WebElement in the cache so when we run the test next time, it will take the WebElement from the cache instead of searching for it on the web page. This will help in saving the execution time.

public String getMyAccountPageTitle() {
return this.myAccountTitle.getText();
}

The getMyAccountPageTitle() will return the text from the WebElement myAccountTitle in String format that will help us in performing assertion for the title in the test.

Need a quick placeholder image for your project? Use our online placeholder image generator tool that helps you generate customizable images for your projects.

The next step that we need to take care of is to locate the Logout link that will be displayed after the successful login on the My Account page.

There are two ways to locate this Logout link, one is using the LinkText locator strategy, and the second is using the CSS Selector locator strategy where we use the Selector — “#column-right > div > a:nth-child(14)”. Let’s use the @FindAll annotation and add these locator strategies to locate the link.

Below is the WebElement variable logoutLink declared to locate the link using @FindAll annotation.

@FindAll({
@FindBy(how = How.LINK_TEXT, using = "Logout"),
@FindBy(how = How.CSS, using = "#column-right > div > a:nth-child(14)")
})
private WebElement logoutLink;

A new method name logoutFromECommercePlayground() is created in the MyAccount Page that will interact with the logout link by performing a click on it.

public void logoutFromEcommercePlayground() {
this.logoutLink.click();
}

We will be calling the initElements() method from the PageFactory class in the constructor of the MyAccountPage class like we did in the LoginPage class.

public class MyAccountPage {

public MyAccountPage(final WebDriver driver) {
PageFactory.initElements(driver, this);
}

@FindBy(css = "#content > div:nth-child(1) h2")
@CacheLookup
private WebElement myAccountTitle;

public String getMyAccountPageTitle() {
return this.myAccountTitle.getText();
}

@FindAll({
@FindBy(how = How.LINK_TEXT, using = "Logout"),
@FindBy(how = How.CSS, using = "#column-right > div > a:nth-child(14)")
})
private WebElement logoutLink;

public void logoutFromEcommercePlayground() {
this.logoutLink.click();
}
}

With the implementation of the Logout step, we have completed the part of writing the Page objects. Now, let’s write the test.

public class LambdaTestEcommercePlaygroundTests extends BaseTest {

@Test
public void testLogin() {
this.driverManager.getDriver().get("https://ecommerce-playground.lambdatest.io/index.php?route=account/login");
final LoginPage loginPage = new LoginPage(this.driverManager.getDriver());
final MyAccountPage myAccountPage = loginPage.performLogin("john+2@gmail.com", "Pass@1234");

assertEquals(myAccountPage.getMyAccountPageTitle(), "My Account");
myAccountPage.logoutFromEcommercePlayground();

}
}

The first statement in the testLogin() method navigates to the LambdaTest eCommerce website. Next, the LoginPage class is instantiated, where we pass on the WebDriver instance using the drivermanager class’ getDriver() method.

The LambdaTestPlayGroundTests class is extended by the BaseTest class that takes care of the WebDriver initialization and teardown using the DriverManager class.

public class BaseTest {

protected DriverManager driverManager;

@BeforeMethod(alwaysRun = true)
public void testSetup() {
this.driverManager = new DriverManager();
this.driverManager.createChromeDriverInCloud();
}

@AfterMethod(alwaysRun = true)
public void tearDown() {
this.driverManager.quitDriver();
}
}

The DriverManager class takes care of all the setup and configuration of the WebDriver interface. As we must run the tests in the LambdaTest cloud grid, the createChromeDriverInCloud() method from the DriverManager class will help us start a session.

LambdaTest is an AI-powered test orchestration and execution platform for Selenium testing with Java that offers automated testing on many browsers and operating systems. It enables parallel testing, local testing, and integration with popular Java testing frameworks like TestNG, JUnit, etc.

It supports online Selenium Grid for scalable testing and provides features such as automated screenshot capture, video recording, network simulation, and seamless integration with CI/CD pipelines, making it a comprehensive platform for developers to ensure their web applications function reliably across diverse environments.

Tired of messy, unorganized XML code? Our XML Stringify tool makes formatting a breeze, allowing you to quickly and easily convert your code into a readable string

You can also have a detailed look at this tutorial to start automation testing on LambdaTest.

Subscribe to the LambdaTest YouTube Channel for software testing tutorials around Selenium, Playwright testing, and more.

public class DriverManager {

protected WebDriver driver;
private static final String LT_USERNAME = System.getProperty("LT_USERNAME");
private static final String LT_ACCESS_KEY = System.getProperty("LT_ACCESS_KEY");
private static final String GRID_URL = "@hub.lambdatest.com/wd/hub";

public void createChromeDriverInCloud() {
final ChromeOptions browserOptions = new ChromeOptions();
browserOptions.setPlatformName("Windows 10");
browserOptions.setBrowserVersion("114.0");
final HashMap<String, Object> ltOptions = new HashMap<>();
ltOptions.put("username", LT_USERNAME);
ltOptions.put("accessKey", LT_ACCESS_KEY);
ltOptions.put("resolution", "2560x1440");
ltOptions.put("selenium_version", "4.0.0");
ltOptions.put("build", "LambdaTest ECommerce Playground Build");
ltOptions.put("name", "LambdaTest ECommerce Playground Tests");
ltOptions.put("w3c", true);
ltOptions.put("plugin", "java-testNG");
browserOptions.setCapability("LT:Options", ltOptions);
try {
this.driver = new RemoteWebDriver(new URL(format("https://{0}:{1}{2}", LT_USERNAME, LT_ACCESS_KEY, GRID_URL)), browserOptions);
} catch (final MalformedURLException e) {
throw new Error("RemoteDriver's URL not set correctly!", e);
}
this.driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
}

public WebDriver getDriver() {
return this.driver;
}

public void quitDriver() {
this.driver.quit();
}
}

These desired capabilities in the createChromeDriverInCloud() method can be easily copied using LambdaTest’s Capabilities Generator.

Coming back to the tests, next, we need to perform the login by calling the performLogin() method from the LoginPage class and passing on the email address and password in the respective fields.

The performLogin() method already returns a new instance of the MyAccountPage class; we don’t need to instantiate the MyAccountPage class in the test method explicitly.

After successful login, the next statement of code will perform the assertion to check that the My Account page title is “My Account”. Finally, it will locate the Logout link and click on it. With this, the test scenario is marked complete.

Test Execution

The following testng.xml file is created that will help us in executing the test using TestNG.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="LambdaTest ecommerce playground website test suite ">
<test name="Page Factory demo tests using LambdaTest ECommerce Playground">
<classes>
<class name="io.github.mfaisalkhatri.tests.LambdaTestEcommercePlaygroundTests">
<methods>
<include name="testLogin"/>
</methods>
</class>
</classes>
</test> <!-- Test -->
</suite> <!-- Suite -->

As we need to execute the tests on LambdaTest Cloud grid we need to provide the following secret values in the Edit Configuration window in the IDE as follows. These values can be found in the Password & Security section after logging in to the LambdaTest website.

-DLT_USERNAME=< LambdaTest Username >
-DLT_ACCESS_KEY=< LambdaTest Access Key >

To execute the tests, right click on the testng.xml file and select the option “Run ‘…/testng.xml’”.

Simplify your data export process with our efficient SQL to CSV Converter. Convert SQL queries to CSV format seamlessly and unlock data versatility. Try it now.

Below is the screenshot of the tests run from IntelliJ.

We can check the test execution details in the LambdaTest Dashboard, which shows the granular details of the test, like OS, browser name, version, and logs.

Food for Thought 💡

As per my experience, the Page Object Model offers more leverage than the Page Factory Model. In Page Factory, we can only define a WebElement or List < WebElements >; hence, it restricts the usage of the By class of Selenium WebDriver. This can restrict us from using different Expected Conditions while using Explicit Wait.

Get faster loading times and better user experience with our efficient JSON Stringify tool. Quickly compress your JSON data with ease and optimize your website now.

Final Thoughts

@FindBy, @FindBys, and @FindAll annotations can be used to implement Page Factory Model in Selenium WebDriver. These are quite neat and clear annotations as we don’t have to use the findElement/findElements method to search for a webelement. Also, we can use the @CacheLookup annotation, which allows us to save the WebElement in the cache so that when the tests run next time, the WebElement is fetched from the cache, thus saving time. However, we need to call the intiElements() method from the PageFactory class in every page object class; otherwise, these annotations won’t work.

The Page Factory Model has advantages and disadvantages; we can check out what suits us the best and move forward to use the model in the automation suite.

How to Handle ElementClickInterceptedException in Selenium Java

Faisalkhatri123 — Thu, 21 Sep 2023 08:18:19 +0000

Selenium is one of the most popular automation testing frameworks organizations use to automate their websites. With Selenium’s 4.0.0 release, multiple breaking changes have been introduced, like WC standardization, Selenium Manager, Chrome DevTools, etc.

With all these features, it has made the test automation engineer’s life easy by removing the complexities like adding executable driver’s path for browser drivers, browser compatibility issues, etc., and helping them to write the automated tests faster and more comfortably.

When it comes to test automation, automation engineers (count me in too :)) often struggle through a common problem, i.e., getting exceptions when running the tests. There are different exceptions in Selenium that test (or automation) engineers come across when performing test automation. Some common exceptions are NoSuchElementException, TimeoutException, SessionNotCreatedException, StaleElementReferenceException, ElementClickInterceptedException, etc.

In this Selenium Java tutorial, we will discuss the nitty-gritty of ElementClickInterceptedException in Selenium and ways to mitigate the exception.

So, let’s get started.

In this flutter automation testing tools tutorial, we will discuss how to test flutter apps manually and automation on real device cloud

What is an ElementClickInterceptedException?

ElementClickInterceptedException occurs when the click command cannot be executed on the WebElement as it is not clickable. This exception typically occurs when another WebElement overlaps the WebElement that somehow receives the click.

As we use the Java programming language in this blog, the exception name ElementClickInterceptedException is used here. It might change in the case of other programming languages as below –

PROGRAMMING LANGUAGE	EXCEPTION NAME
Java	ElementClickInterceptedException
C#	OpenQA.Selenium.ElementClickInterceptedException
Ruby	ERROR: element click intercepted
Python	selenium.common.exceptions.ElementClickInterceptedException
JavaScript	WebDriverError: element click intercepted:

The following exception log is printed in the console when ElementClickInterceptedException is thrown using Selenium with Java:

The logs show that instead of the actual element on which the click command was called, it was not clickable as some other element covered it; hence, the exception was thrown.

Different reasons can cause the ElementClickInterceptedException in Selenium. Let’s learn about them in the next section.

Mobile emulators online from LambdaTest allows you to seamlessly test your mobile applications, websites,and web apps on mobile browsers and mobile devices.

What are the causes of ElementClickInterceptedException?

The following are the major causes that can lead to ElementClickInterceptedException thrown by Selenium WebDriver:

WebElements overlap each other
WebElement is disabled
WebElement is not visible or not available in the DOM currently at the time when the click command was executed. This can happen due to a slow Internet connection, and the automation scripts are executed while the web page is not loaded.

Let’s discuss these causes in detail one by one.

Cause 1: WebElements overlapping with each other

Overlapping elements on the webpage can cause problems in running test automation scripts. When interactions are done with such elements, we often receive different exceptions based on the interactions performed. However, if we try to click on the element, an ElementClickInterceptedException will be thrown.

Here is an example of the web page from the UITestingPlayground website that has the name field overlapped with some other WebElement.

So, ideally, to interact with the name field, we will have to scroll to get the name field into view and then perform the interaction on it to handle the ElementClickInterceptedException in Selenium.

Cause 2: WebElement is disabled

Another reason for getting the ElementClickInterceptedException in Selenium is that the WebElement might be disabled, and Selenium may not be able to perform clicks as desired through the automation script.

This may happen in scenarios like filling up the user registration form on the website, where the Submit button remains disabled unless all the mandatory fields are filled up correctly. So, in case the Submit button is clicked while it is still disabled, Selenium WebDriver might throw an ElementClickInterceptedException.

Cause 3: WebElement was not visible when the click command was executed

When the tests are executed using test automation scripts, web page load time should also be considered. As the automation scripts continue to execute line by line, once the first line is executed, the program moves to the next line.

Consider an example of an eCommerce website with multiple JavaScript codes running on the web page.

We locate a product and click the Add to Cart button next to it as a part of our test scenario. There is a higher chance of getting an ElementClickInterceptedException as the webpage is not completely loaded, and we are trying to click on a WebElement that is currently not visible in DOM.

Having learned about the causes for ElementClickInterceptedException in Selenium, let’s now proceed and check out the multiple ways to handle the exception and run our Selenium test automation scripts hassle-free.

How to handle ElementClickInterceptedException in Selenium?

Before we write the test automation scripts, it would be good to share the details of the tools used in this blog to demo the solutions for handling the ElementClickInterceptedException in Selenium.

Programming Language — Java 17
Web Automation tool — Selenium WebDriver — version — 4.10.0
Build Tool — Maven
Test Runner — TestNG
Cloud Platform to run web automation tests — LambdaTest

Project Setup

The Maven project has been created, and the respective dependencies for TestNG and Selenium WebDriver have been updated in the pom.xml. The build and plugins section in the pom.xml are updated with the maven-sure-fire and maven-compiler plugins to execute the tests using the command line interface. We will use different test scenarios in this project to demo how to handle the ElementClickInterceptedException in Selenium.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>io.github.mfaisalkhatri</groupId>
<artifactId>selenium-exceptions-demo</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>

<name>selenium-exceptions-demo</name>
<url>http://maven.apache.org</url>

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<selenium.java.version>4.10.0</selenium.java.version>
<testng.version>7.8.0</testng.version>
<maven.compiler.version>3.11.0</maven.compiler.version>
<surefire-version>3.1.2</surefire-version>
<java.release.version>17</java.release.version>
<maven.source.encoding>UTF-8</maven.source.encoding>
<suite-xml>test-suite/testng.xml</suite-xml>
<argLine>-Dfile.encoding=UTF-8 -Xdebug -Xnoagent</argLine>

</properties>

<dependencies>
<!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium.java.version}</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.testng/testng -->
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>${testng.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.version}</version>
<configuration>
<release>${java.release.version}</release>
<encoding>${maven.source.encoding}</encoding>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire-version}</version>
<executions>
<execution>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
<properties>
<property>
<name>usedefaultlisteners</name>
<value>false</value>
</property>
</properties>
<suiteXmlFiles>
<suiteXmlFile>${suite-xml}</suiteXmlFile>
</suiteXmlFiles>
<argLine>${argLine}</argLine>
</configuration>
</plugin>
</plugins>
</build>
</project>

For better maintainability and re-using the page objects, the Page Object Model (POM) has been used in this project. It helps remove code duplication and separate the page objects from the tests, thus helping write cleaner automation tests.

In this section, we will be going through multiple solutions that can be used to handle the ElementClickInterceptedException in Selenium. We will use a couple of websites to demo the solution.

Perform browser test automation on the most powerful cloud infrastructure. Leverage LambdaTest automation testing for faster, reliable and scalable experience on cloud.

Solution 1: Using Explicit Waits in Selenium WebDriver

Performing click action on the WebElement that did not get loaded properly on the web page is one of the causes that might lead to ElementClickInterceptedException in Selenium. To resolve this, we can use the Explicit Waits in Selenium WebDriver.

We can use the ExpectedConditions like elementToBeClickable to be sure that the WebElement we are clicking is clickable. We may also use the invisibilityOfElementLocated method. This comes in handy in case WebElements like notifications or snack bars overlap.

Test Scenario

Navigate to the OWASP Juice Shop website.
Open the Login Page.
Login to the website using valid credentials.
Perform assertion for successful login by checking that the Logout link is displayed.

Home Page of OWASP Juice Shop website

Login Page of OWASP Juice Shop website

In this scenario, when we try to click on the Login button on the login page after entering valid credentials, it throws ElementClickInterceptedException as the login button is overlapped by the language notification snack bar.

Implementation

In this scenario, we will first navigate to the Homepage of the OWASP Juice Shop website and close all the pop-up messages so we can smoothly run our automation tests.

Next, we need to locate and click on the Account link to open it and locate the Login link. We will be navigated to the Login Page by clicking the Login link.

The following is the code from the HomePage class.

public class HomePage {

private WebElement dismissBtn() {
return getDriver().findElement(By.cssSelector("button[aria-label=\"Close Welcome Banner\"]"));
}

public void closeBanner() {
dismissBtn().click();
}

private WebElement meWantItBtn() {
return getDriver().findElement(By.cssSelector("a[aria-label=\"dismiss cookie message\"]"));
}

public void closeCookieMessage() {
meWantItBtn().click();
}

protected WebElement accountLink() {
return getDriver().findElement(By.id("navbarAccount"));
}

private WebElement loginLink() {
return getDriver().findElement(By.id("navbarLoginButton"));
}

public LoginPage navigateToLoginPage() {
closeBanner();
closeCookieMessage();
accountLink().click();
loginLink().click();
return new LoginPage();
}

}

The following are two pop-up messages appearing on the website’s Home page that need to be handled first before moving ahead to the Login page. You can learn more about it through this blog on handling pop-ups in Selenium.

Deep dive to learn about test automation, its uasage, types and also gain insights on how to get started with automated testing.

Let’s search for the selectors of the Dismiss button in the DOM using Chrome browser’s Developer Tools.

Once we inspect the Dismiss button in the Developer Tools, it takes us to the HTML tag button where the label is “Close Welcome Banner”. We can use this as the Selector for locating the Dismiss button. You can learn more about different locator strategies through this tutorial on locators in Selenium.

We will be using the CSS Selector locator strategy to locate the Dismiss button, and the Selector will be “button[aria-label=”CloseWelcome Banner”]”. Similarly, we can use the Developer Tools window to find other WebElements on this website; we can use the Developer Tools window.

To handle the first popup, i.e., Welcome pop-up, the dismissBtn() method is created in the HomePage class that locates the Dismiss button. The closeBanner() method clicks on the Dismiss button.

To handle the next pop-up displayed on the screen’s right-hand corner, the meWantItBtn() method is created in the HomePage class that locates the Me Want it! button, and the closeCookieMessage() method clicks on Me Want it! button.

Next, we move to the Account Link, open it, and click the Login link to navigate to the Login page. The accountLink() and loginLink() methods locate the WebElements for Account Link and Login Link.

The navigateToLoginPage() method performs the actions for closing the banner. The cookie message clicks on the Account and Login links and finally returns a new instance of the LoginPage class.

On the Login page, as the language notification snackbar is displayed that overlaps the Login button, we need to wait for the notification to disappear so we can move ahead and click on the button and avoid the ElementClickInterceptedException.

The following code is from the LoginPage class that handles the login actions.

public class LoginPage {

private final HomePage homePage;

public LoginPage() {
this.homePage = new HomePage();
}

private WebElement emailField() {
return getDriver().findElement(By.id("email"));
}

private WebElement passwordField() {
return getDriver().findElement(By.id("password"));
}

private WebElement loginBtn() {
return getDriver().findElement(By.id("loginButton"));
}

private void waitForSnackBarToDisappear() {
final WebDriverWait wait = new WebDriverWait(getDriver(), Duration.ofSeconds(10));
wait.until(ExpectedConditions.invisibilityOfElementLocated(By.cssSelector(".mat-simple-snack-bar-content")));
}

public ProductPage login(final String email, final String password) {
emailField().sendKeys(email);
passwordField().sendKeys(password);
clickLoginBtn();
return new ProductPage();
}

public boolean checkLogoutLinkIsDisplayed() {
openAccountMenu();
return getDriver().findElement(By.id("navbarLogoutButton")).isDisplayed();
}

public void openAccountMenu () {
this.homePage.accountLink().click();
}

public void clickLoginBtn() {
waitForSnackBarToDisappear();
loginBtn().click();
}
}

The invisibilityOfElementLocated() method from the ExpectedConditions class is used here to wait till the time the WebElement for the snackbar notification disappears so we can click on the Login button.

The waitForSnackBarToDisappear() method implements the logic discussed.

Which are the most wanted automation testing tools that have climbed the top of the ladder so far? Let's take a look

This waitForSnackBarToDisappear() method is called before the Login button is clicked using the clickLoginBtn() method.

Finally, the login() method is created to perform actions of entering values in email and password fields and clicking on the Login button.

Let’s write the test now and check out the actual working of the scenario. Here is the test method that is available in the JuiceShopTests class.

private ProductPage productPage;

@Test
public void testLogin() {
getDriver().get("https://juice-shop.herokuapp.com/#/");
final var loginPage = new HomePage().navigateToLoginPage();
this.productPage = loginPage.login("demo+1@gmail.com", "Juice@1234");
assertTrue(loginPage.checkLogoutLinkIsDisplayed());
}

In this test, we perform the steps to navigate to the OWASP Juice Shop website and call the navigateToLoginPage() method that will open the Login page after which the login() method will be called that has valid credentials as the parameters to login into the website.

Finally, the assertion is performed to check that the Logout link is displayed; this completes the login test.

Test Execution

To run the test, right-click on the testng.xml and select the option Run …/testng.xml.

Below is the screenshot from the testng.xml file.

Before executing the test, it’s a good idea to check the ElementClickInterceptedException. To do this, let’s temporarily disable the waitForSnackBarToDisappear() method within the clickLoginBtn() method.

Here is the test execution result that shows the ElementClickInterceptedException in Selenium was thrown, and the test failed.

Now, let’s uncomment the waitForSnackBarToDisappear() method in the clickLoginBtn() method and rerun the test.

ElementClickInterceptedException in Selenium was handled successfully, and the tests passed.

Solution 2: Locate the overlay WebElement and click on it

The second solution we can try to handle the ElementClickInterceptedException in Selenium is locating the overlay WebElement and clicking on it. Then, perform the next steps to click on the required WebElement.

Test Scenario

Navigate to the OWASP Juice Shop website.
Login to the website.
From the product page, add a product to the cart.
Check that the cart shows “1” product added to it

In this scenario, as soon as the product page is loaded after successful login, it is overlapped with an overlay screen that intercepts the click on the Add to Basket button on the page, and an ElementClickInterceptedException in Selenium is thrown.

Which are the most wanted automation testing tools that have climbed the top of the ladder so far? Let's take a look

Implementation

As we already discussed the login in Scenario 1, we will not be going into details for login again here. We will focus on the last 2 steps in this scenario: adding a product to the cart and checking that the cart shows “1” product added.

The following code is written in the ProductPage class that helps locate the WebElements and perform interactions on it.

public class ProductPage {

private WebElement appleJuiceAddToBasketBtn() {
return getDriver().findElement(By.cssSelector("mat-grid-tile:nth-child(1) &gt; div &gt; mat-card &gt; div:nth-child(2) &gt; button"));
}

private WebElement overlay() {
return getDriver().findElement(
By.cssSelector(".cdk-overlay-backdrop.cdk-overlay-transparent-backdrop.cdk-overlay-backdrop-showing"));
}
public void addAppleJuiceToCart() {
overlay().click();
appleJuiceAddToBasketBtn().click();
}

public String itemsInBasket() {
return getDriver().findElement(By.cssSelector("span.warn-notification")).getAttribute("innerText");
}
}

overlay() method locates and returns the WebElement for the overlay screen and is called in the addAppleJuiceToCart() method.

itemsInBasket() method returns the value of the items in the cart WebElement in the string format that will help us perform assertion.

Here is the test method testAddProductToBasket() available in the JuiceShopTests class.

We have already covered the login step in Scenario 1. This Scenario 2 test will run after the Scenario 1 test, and the test order will be handled in testng.xml.

@Test
public void testAddProductToBasket() {
this.productPage.addAppleJuiceToCart();
assertEquals(this.productPage.itemsInBasket(), "1 ");
}

Test Execution

Here is the screenshot of the testng.xml file that will be used to run the test.

Before running the tests, let’s comment out the statement where we are locating the overlay screen and clicking on it to replicate the ElementClickInterceptedException in Selenium.

The screenshot below shows the test execution result with the ElementClickInterceptedException.

If you check the logs closely, you will notice that it provides us with the WebElement locator for the overlay screen. This can be used directly to locate and click on the overlay screen WebElement.

Let’s uncomment the statement that clicks on the overlay WebElement and handles the ElementClickInterceptedException in Selenium.

Let’s re-run the test and check the output.

The tests passed successfully using the solution where we clicked the overlay screen before clicking the Add to Basket button.

Mobile emulators online from LambdaTest allows you to seamlessly test your mobile applications, websites,and web apps on mobile browsers and mobile devices.

Solution 3: Clicking on the WebElement using JavaScriptExecutor

The third solution for handling the ElementClickInterceptedException in Selenium is using the JavaScriptExecutor to click on the WebElement. This is recommended in case the first two solutions don’t work. We can use this solution to directly click on the WebElement if we need a simple workaround.

Test Scenario

Navigate to LambdaTest’s official website.
Click and Play the video displayed on the right-hand side of the window.
To verify that the video was played successfully, check that the close button on the video player is displayed.

In this scenario, if we try to click on the video directly by clicking on it, it throws an ElementClickInterceptedException. So, we will be using the JavaScriptExecutor and handling it.

Implementation

The implementation of this scenario is quite easy. We will navigate to the Home page, locate the web element for the video, and click on it.

Finally, the assertion will be performed to check that the close button is displayed on the video player.

The below code is from the HomePage class created that takes care of the page objects and their respective interactions.

public class HomePage {

private WebElement videoLink() {
return getDriver().findElement(By.cssSelector("div > div:nth-child(1) > span > picture > img"));
}

public void clickOnVideoLink() {
videoLink().click();
}

public void clickOnVideoLinkUsingJSExecutor() {
final JavascriptExecutor executor = (JavascriptExecutor) getDriver();
executor.executeScript("arguments[0].click();", videoLink());
}

public WebElement videoCloseBtn() {
final WebDriverWait wait = new WebDriverWait(getDriver(), Duration.ofSeconds(20));
return wait.until(ExpectedConditions.elementToBeClickable(By.cssSelector(".popup span.close")));
}

}

The videoLink() method locates the video link on the Home page. The clickOnVideoLinkUsingJSExecutor() method performs click on the link using JavaScriptExecutor, and the clickOnVideoLink() method uses the native click method to perform click on the video link.

videoCloseBtn() method returns the WebElement for Close button on the video player. This method will be further used in tests to write assertions to check that the button is displayed.

The test code is written for testing the working of this scenario.

@Test
public void testHomePage() {
getDriver().get("https://www.lambdatest.com");
final HomePage homePage = new HomePage();
homePage.clickOnVideoLinkUsingJSExecutor();
assertTrue(homePage.videoCloseBtn().isDisplayed());
}

The test is straightforward; it will first navigate to the LambdaTest’s official website, click on the video link and perform an assertion to check that the close button is displayed.

Test Execution

The following test block in testng.xml will execute this scenario for us.

Let’s first recreate the case where ElementClickInterceptedException in Selenium is thrown when the video is clicked on the Home page without using the JavaScriptExecutor.

We will comment on the statement that executes the script to click with JavaScriptExecutor and perform a normal click on the video.

The following is the output of the test execution that shows that the ElementClickInterceptedException in Selenium was thrown while trying to click on the video.

Now, let’s replace the homepage.clickOnVideoLink() method with the homePage.clickOnVideoLinkUsingJsExecutor() and re-run the test.

In this Appium tutorial, learn about Appium and its benefits for mobile automation testing. Take a look at how Appium works and see how to perform Appium testing of your mobile applications

Using JavaScriptExecutor, the ElementClickInterceptedException in Selenium was handled successfully, and the tests passed.

Solution 4: Scrolling into the View using JavaScriptExecutor before clicking on the WebElement

The fourth solution that can be used for handling the exception is scrolling into the view. Hence, the WebElement is visible on the window and can be clicked. Using this solution, we will first scroll the web page to the point where the element is clearly visible on the page and then perform a click on it.

This can be done using the JavaScriptExecutor only; the only change is the argument that we pass in the executeScript() method to execute the JavaScript. Here, we will be passing the scrollIntoView() argument.

Test Scenario

Navigate to the UITestingPlayground website’s Overlapped Element window.
Enter the value in the Id and Name fields.
Perform assertion by checking the value typed in the Name field.

UITestingPlayground website’s Overlapped Element window

In this website, the Name field is overlapped by another WebElement, so if we try to click to type some value in the field, it will throw an ElementClickInterceptedException in Selenium.

Implementation

In this scenario, we will navigate the UITestingPlayground website’s Overlapped Element web page. Next, we will scroll into view using JavaScriptExecutor and then type the value in the Name field.

Finally, assertion will be performed to check the value entered in the Name field.

The below code is available in the OverLapElementPage class.

public class OverLapElementPage {

private WebElement idField() {
return getDriver().findElement(By.id("id"));
}

private WebElement nameField() {
return getDriver().findElement(By.id("name"));
}

public void fillForm(final String id, final String name) {
idField().click();
idField().sendKeys(id);
final var executor = (JavascriptExecutor) getDriver();
executor.executeScript("arguments[0].scrollIntoView(true);", nameField());
nameField().click();
nameField().sendKeys(name);
}

public String textInNameField() {
return nameField().getAttribute("value");
}
}

The idField() and nameField() methods locate and return the WebElements for the Id and the Name fields, respectively. Using the fillForm() method, we can click on the Id and Name fields and type values in them. However, before we click on the Name field, we will use the JavaScriptExecutor to scroll into view.

The following line of code will help scroll to the web page to the point where the Name field is visible in the viewport.

Below is the test written for this scenario. It is available in the UITestingPlaygroundTests class

public class UITestingPlaygroundTests extends BaseTest{

@Test
public void testOverLappingElement() {
getDriver().get("http://www.uitestingplayground.com/overlapped");

final var overLapElementPage = new OverLapElementPage();
final String id = "ID7763";
final String name = "Faisal K";
overLapElementPage.fillForm(id, name);

assertEquals(overLapElementPage.textInNameField(), name);

}
}

The first statement of code in the test navigates to the UITestingPlayground website’s Overlapped element page. Next, we call the fillForm() method from the OverLapElementPage class to fill values in the Id and Name fields.

Finally, assertion is performed to check the values typed in the Name field.

Test Execution

The following test block is added in the testng.xml to execute the tests for this scenario.

Let’s first replicate the ElementClickInterceptedException thrown due to the Name field getting overlapped with another WebElement. To do so, we must comment out the JavaScriptExecutor statement in the fillForm() method.

On executing the test, the ElementClickInterceptedException in Selenium is thrown, as seen in the logs.

Let’s uncomment the JavaScriptExecutor statement in the fillForm() method and rerun the test.

Using the scrollintoView argument in JavaScriptExecutor works perfectly fine handling the ElementClickInterceptedException, and the tests pass.

Solution 5: Using the Actions class of Selenium WebDriver

The next solution we will discuss for handling the ElementClickInterceptedException is using the Selenium WebDriver’s Actions class.

The primary reason for ElementClickInterceptedException in Selenium is that the respective element that needs to be clicked is either overlapped by another element or an overlay screen. So, using the Actions class’s movetoElement() method, we can move the focus to the required WebElement and then perform a click on it.

Test Scenario

Navigate to the LambdaTest eCommerce demo website.
On the Home page, open the Shop by Category side menu.
With the Shop by Category side menu open, click on the Blog main menu.
Verify the title of the Blog page.

LambdaTest eCommerce website demo page

LambdaTest eCommerce website — Blogs menu

In this scenario, after opening the Shop by Category side menu, when we try to click on the Blog main menu, it throws the ElementClickInterceptedException in Selenium. This exception is thrown as the Shop by Category menu overlaps the screen.

Implementation

In this scenario, we will first navigate to the LambdaTest eCommerce demo website and click on the Shop by Category side menu link. Once it opens, we will click on the Blogs menu.

The following code is available in the MainPage class.

public class MainPage {

private WebElement shopByCategoryLink() {
return getDriver().findElement(By.linkText("Shop by Category"));
}

public void openShopByCategoryMenu() {
shopByCategoryLink().click();
}

private WebElement menuBar() {
return getDriver().findElement(By.cssSelector(".entry-section div.navbar-collapse"));
}
private WebElement blogLink() {
return getDriver().findElement(By.linkText("Blog"));
}
public BlogPage navigateToBlogs() {
final Actions actions = new Actions(getDriver());
actions.moveToElement(menuBar()).click().build().perform();
blogLink().click();
return new BlogPage();
}
}

shopByCateogryLink() method locates and returns the WebElement for the menu link. ShopByCategoryMenu() method performs the click on the Shop by Category menu.

The navigateToBlogs() method will help in clicking the Blog menu. The moveToElement() method of the Actions class is used to move the focus to the menu bar so the overlay screen can be removed and we can click on the Blog menu link.

To perform the assertion, we will be checking — “LATEST ARTICLES” in the page header on the Blog page.

The BlogPage class has been created to locate the WebElement for the page header.

public class BlogPage {

public String pageHeader () {
return getDriver().findElement(By.cssSelector(".entry-section div.mz-tab-listing-header h3")).getText();
}
}

The pageHeader() method locates the page header WebElement of a Blog page and returns its text in string format.

This smoke testing tutorial covers what smoke testing is, its importance, benefits, and how to perform it with real-time examples

The following automated test in the LambdaTestEcommerceTest class will help check the scenario with assertion.

public class LambdaTestEcommerceTest extends BaseTest{

@Test
public void testNavigationToBlogsMenu() {
getDriver().get("https://ecommerce-playground.lambdatest.io/");
final var mainPage = new MainPage();
mainPage.openShopByCategoryMenu();
final var blogPage = mainPage.navigateToBlogs();
assertEquals(blogPage.pageHeader(), "LATEST ARTICLES");
}
}

The test is simple to understand. We first navigate to the LambdaTest eCommerce website, open the Shop by Category menu, and then navigate to the Blog page by clicking the Blog menu.

Finally, the assertion is performed to check that the page header is “LATEST ARTICLES”.

Test Execution

The following test block is added in the testng.xml to execute the tests for this scenario

Let’s first try to execute the test by clicking on the Blog menu link directly without using the Actions class.

To do so, we will comment on the statements of code we wrote for using the moveToElement() method from Actions class, in the navigateToBlogs() method.

Let’s run the test and check the output.

We can see the test failing after throwing an ElementClickInterceptedException.

Let’s re-run the test by uncommenting the moveToElement() method statement of the Actions class so it handles the ElementClickInterceptedException in Selenium.

Here is the output of the test running successfully.

A complete Manual testing tutorial covering all aspects of Manual testing, including strategies and best practices.

Solution 6: Setting custom resolution for the browser

The next solution is simple: maximizing the browser after we create the WebDriver instance. We can also set the custom window resolution for the browser in case we don’t want to run the tests by maximizing the browser window.

As per Selenium Best Practices, it is advisable to maximize the window or use a custom window size that opens the window with wide mode for a uniform automation experience and to avoid elements overlapping issues related to ElementClickInterceptedException.

Going through all the previous solutions, it can be noted that ideally, the WebElements overlap or are not in the viewport. Hence, the ElementClickInterceptedException in Selenium is thrown while we try to click on the WebElement.

So, by maximizing or resizing the window to a custom resolution, we can get a better window view where all elements are ideally visible, locatable, and can be clicked easily.

Maximizing the browser window

The following line of code can be used to maximize the browser

Customizing the browser screen resolution

There are two ways in which we can customize the resolution before we start running our automation tests.

Customizing the window size by adding arguments using the BrowserOptions class
Customizing the window size in a cloud grid like LambdaTest

Resizing the browser window using Browser Options

The respective class of browser options can be used to add arguments and resize the window. For example, we can resize the window of Chrome browser using the ChromeOptions class as follows:

private static void setupChromeDriver () {
final ChromeOptions options = new ChromeOptions ();
options.addArguments ("--no-sandbox");
options.addArguments ("--disable-dev-shm-usage");
options.addArguments ("--window-size=1050,650");
driver = new ChromeDriver(options);
driver.manage().window().maximize();
}

The value for the screen resolution can be passed in the argument “–window-size= < resolution in x,y format > ”:

Likewise, the same arguments can be used with FirefoxOptions and EdgeOptions classes as well for resizing the window in Firefox and Edge browsers respectively.

Resizing the browser window in LambdaTest Cloud Grid

LambdaTest is an AI-powered test orchestration and execution that allows you to perform manual and automation testing on over 3000+ real browsers, devices, and platforms. It provides a reliable and scalable cloud grid to conduct Java automation testing at scale.

For Selenium Java testing, it provides the LambdaTest Capabilities Generator website that helps set all the capabilities using GUI. The code can be copied and used in the test configuration and setup.

You can follow the LambdaTest YouTube Channel and stay updated with the latest tutorials around Selenium testing, Cypress testing, CI/CD, and more.

To set the capabilities for screen resolution using the capabilities generator website, we need to click on Configure Advanced Capabilities >> Screen Resolution and select the desired screen resolution as required.

Once we select the resolution, the code is autogenerated and can be copied and pasted into the test automation scripts.

These capabilities are set in the DriverManager class in the setupRemoteDriver() method.

On executing the tests on the LambdaTest Cloud grid, we can check out the resolution details on the LambdaTest Automation Dashboard.

Solution 7: Using Thread.sleep() to debug the Exception

Thread.sleep() is a kind of hard wait hence, it is not a recommended solution to be used in the test automation. However, when required we can use the Thread.sleep() method to debug the issue to check if waiting for a certain amount of time does make the automation test work successfully and allows clicking on the WebElement.

If the WebElement is clickable ideally after applying Thread.sleep(), we may move to some of the ideal solutions that we discussed above.

Which solution to choose for handling ElementClickInterceptedException?

We discussed around 7 solutions to help us handle the ElementClickInterceptedException in Selenium. We should try using the maximize window or setting it in custom size so it opens in wide mode. This can help handle the overlapping elements quickly.

If maximizing the window does not work, we can apply the Explicit Wait on the element, wait for the element to be clickable, and then perform a click on it.

Ideally, JavaScriptExecutor should work as an ideal solution using click or scroll to view arguments.

Thread.sleep() is not a recommended solution to be used. However, we can use it for debugging purposes.

In this tutorial on Agile testing, let's deep dive into the history of Agile testing, its advantages, disadvantages, methods, quadrants, and best practices.

Final Thoughts

The primary reason that may lead to the ElementClickInterceptedException in Selenium is that the WebElement required to be clicked may overlap with some other element. We discussed multiple solutions to handle this exception. The simplest solution we can try firsthand is to maximize the browser window or set a custom size that may make all the WebElements visible and interactable. However, if that still doesn’t work, we can try the other solutions discussed in this blog.

Happy Testing!

Selenium Manager in Selenium 4.11.0: New Features and Improvementsx

Faisalkhatri123 — Wed, 06 Sep 2023 08:09:32 +0000

Selenium WebDriver, as everyone knows, is used for automating browsers. It is used widely by many organizations for web automation testing. Using Selenium WebDriver, you can automate all the modern browsers like Google Chrome, Mozilla Firefox, Microsoft Edge, and Safari. With the release of the Selenium 4 version, WebDriver APIs run on the W3C standard protocol making Selenium 4 W3C Compliant.

Previously, in older versions of Selenium, it was required to provide the driver executable path to run the automated tests on the respective browser. Third-party libraries like WebDriverManager were used to automate the manual process of updating browser drivers.

With Selenium’s version 4.6.0, Selenium Manager was introduced, providing a huge relief to the automation test engineers as it handles the browser drivers under the hood, so you don’t have to worry about the browser drivers.

In this blog, let’s learn about Selenium WebDriver’s latest release, i.e., version 4.11.0, which ships the following features related to Selenium Manager:

Support for Chrome for Testing endpoints for Automated Chrome Management and ChromeDriver Management.

In this tutorial, learn what is Regression testing, its importance, types, and how to perform it.

What is Selenium Manager?

Selenium Manager is a binary tool generated using Rust that provides automated driver management for Google Chrome, Mozilla Firefox, and Microsoft Edge. Selenium bindings use Selenium Manager by default, so there is no need to download it or add its dependency in the project to use it. It is still in Beta; however, it is becoming a relevant component of Selenium.

// Detect dark theme var iframe = document.getElementById('tweet-1603288968925044737-545'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1603288968925044737&theme=dark" }

Selenium Manager’s Automated Driver Management

As discussed in the earlier section, Selenium Manager is used for automated driver management. When the following statement of code gets executed to run the browser using Selenium WebDriver, Selenium Manager is invoked and checks for the browser version of the respective browser installed on your machine. After downloading the browser driver, it caches it in the local (~/.cache/selenium) folder. This ensures the smooth execution of future automated tests for the same browser/driver version.

This caching of the drivers is done in the same folder location across macOS, Windows, and Linux.

WebDriver driver = new ChromeDriver();

Below is the pictorial representation of Selenium Manager’s automated driver management.

When the Selenium automation tests are executed, and no browser driver executable path is provided, Selenium Manager performs the following steps to manage the drivers in an automated way:

Step 1 — Browser version discovery

Selenium Manager checks the browser version installed on the machine where the web automation tests are executed. For example, for Chrome browser version discovery, Selenium Manager uses the command google-chrome –version.

Step 2 — Driver version discovery

On getting the browser version from Step 1, the respective driver version is identified using the online metadata maintained by the browser vendors, e.g., ChromeDriver, geckodriver, or msedgedriver.

Step 3 — Driver Download

The driver artifact is downloaded using the driver URL obtained from Step 2. This artifact is uncompressed and stored locally.

Step 4 — Driver Cache

All the driver binaries are saved to the local cache (~/.cache/selenium). This helps in re-using the same browser driver and executing the tests again if, in the future, the tests are run on the same browser/driver version.

Driver Cache — Windows

Driver Cache — macOS

Which are the most wanted tools for automation testing that have climbed the top of the ladder so far? Let’s take a look.

Running Tests on Chrome, Firefox, and Edge browsers using Selenium Manager

Let’s now get into the implementation and check out the real-time working of Selenium Manager. But, before we move toward the demo following are some of the details related to the technical stack that we will be using:

Programming Language — Java 17
Web Automation Tool — Selenium WebDriver (4.11.0)
Build Tool — Maven
Test Runner — TestNG

Project Setup

A Maven project has been created, and the Selenium WebDriver and TestNG dependencies are updated in the pom.xml file. Similarly, maven-compiler and maven-surefire plugins are also updated in it.

Dependencies updated in pom.xml

Filename: pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.lambdatest</groupId>
<artifactId>selenium-manager-demo</artifactId>
<version>1.0-SNAPSHOT</version>

<properties>
<selenium-java.version>4.11.0</selenium-java.version>
<webdrivermanager.version>5.4.1</webdrivermanager.version>
<testng.version>7.8.0</testng.version>
<maven.compiler.version>3.11.0</maven.compiler.version>
<surefire-version>3.1.2</surefire-version>
<java.release.version>17</java.release.version>
<maven.source.encoding>UTF-8</maven.source.encoding>
<suite-xml>test-suite/testng.xml</suite-xml>
<argLine>-Dfile.encoding=UTF-8 -Xdebug -Xnoagent</argLine>
</properties>

<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium-java.version}</version>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>${testng.version}</version>
<scope>test</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/io.github.bonigarcia/webdrivermanager -->
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
<version>${webdrivermanager.version}</version>
</dependency>

</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.version}</version>
<configuration>
<release>${java.release.version}</release>
<encoding>${maven.source.encoding}</encoding>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire-version}</version>
<executions>
<execution>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
<properties>
<property>
<name>usedefaultlisteners</name>
<value>false</value>
</property>
</properties>
<suiteXmlFiles>
<suiteXmlFile>${suite-xml}</suiteXmlFile>
</suiteXmlFiles>
<argLine>${argLine}</argLine>
</configuration>
</plugin>
</plugins>
</build>
</project>

Demonstration — Working with Selenium Manager on Chrome, Firefox, and Edge browsers

In this section, we will be going through a demo of three tests that will be running on Chrome, Firefox, and Edge browsers, where we will be instantiating the WebDriver and the browser driver management will be automatically done by Selenium Manager.

Test Scenario 1

Open Chrome browser.
Navigate to LambdaTest’s eCommerce Playground website.
Assert that the page title is “Your Store”.

Test Scenario 2

Open Firefox browser.
Navigate to LambdaTest’s eCommerce Playground website.
Assert that the page title is “Your Store”.

Test Scenario 3

Open Edge browser.
Navigate to LambdaTest’s eCommerce Playground website.
Assert that the page title is “Your Store”.

LambdaTest’s eCommerce Playground Website

Implementation

The following automation tests are written in the SeleniumWebDriverManagerTest class.

public class SeleniumWebDriverManagerTests {
private WebDriver driver;
@Test
public void testChromeLatestVersionWithSeleniumManager() {
this.driver = new ChromeDriver();
this.driver.get("https://ecommerce-playground.lambdatest.io/");

assertEquals(this.driver.getTitle(), "Your Store");
}
@Test
public void testOnFirefoxLatestVersionWithSeleniumManager() {
this.driver = new FirefoxDriver();
this.driver.get("https://ecommerce-playground.lambdatest.io/");

assertEquals(this.driver.getTitle(), "Your Store");
}

@Test
public void testOnEdgeLatestVersionWithSeleniumManager() {
this.driver = new EdgeDriver();
this.driver.get("https://ecommerce-playground.lambdatest.io/");

assertEquals(this.driver.getTitle(), "Your Store");
}

@AfterMethod(alwaysRun = true)
public void tearDown() {
this.driver.quit();
}
}

testChromeLatestVersionWithSeleniumManager() is the code implementation for Scenario 1. It will open LambdaTest’s eCommerce website in the Chrome browser and perform an assertion to match the title.

testOnFirefoxLatestVersionWithSeleniumManager() is the code implementation of Scenario 2. This code snippet launches the website using the Firefox browser and verifies the title through an assertion.

testOnEdgeLatestVersionWithSeleniumManager() implements Scenario 3 and will perform the testing in Edge browser. It will navigate to the website and verify the title.

Notice that in all three tests, we haven’t provided any driver executable path, nor have we used third-party libraries like WebDriverManager. Selenium Manager will automatically handle the browser drivers.

Which are the most wanted automation testing tools that have climbed the top of the ladder so far? Let’s take a look.

Test Execution

Let’s create a testng.xml file and execute all three tests.

Here is the screenshot of the test execution showing that all three tests passed successfully.

Let’s also check the Driver Cache, as the latest browser driver should be downloaded and stored in it.

Selenium Manager Major Changes — Working with Drivers added to the PATH

With the introduction of Selenium Manager, automated driver management is handled for the Selenium bindings. Selenium Manager is a fallback solution when no drivers are specified during setup.

However, Selenium users can continue to manage the drivers manually by putting the drivers on the PATH or using System Properties, or by using third-party libraries like WebDriverManager. Selenium Manager also helps users to notify the potential problems with the drivers on the PATH.

For example, consider a scenario of running the browser automation tests on Chrome browser where the browser drivers are maintained manually by setting it on the environment variable PATH. So, when writing the tests, the latest version of Chrome browser was 113. Hence the respective browser driver of version 113 was downloaded and set in the environment variable PATH.

Now, as Chrome browser has the auto-update feature, it gets updated with the latest version, i.e., 115, in the background. So, if we run the automation tests, it will throw an error stating that “This version of ChromeDriver only supports Chrome version 113” because, with the latest Chrome browser, version 115, the browser driver with version 112 is incompatible.

With Selenium’s 4.11.0 release, when an incompatible browser driver is found on the PATH, the following warning message is displayed in the console logs when Selenium tests are executed; this helps in better visibility of the error.

This shows that when browser drivers are already set in the PATH variable, Selenium Manager will not auto-download the respective browser driver but will show a warning message to update the browser driver manually.

Another approach to consider is leveraging Selenium Manager’s driver management capabilities. By eliminating the need for a driver PATH, Selenium Manager can autonomously identify and download the necessary browser, facilitating the execution of web automation tests.

Demonstration — Checking out the Warning message in Selenium 4.11.0 release for the incompatible browser driver set in the PATH

Test Scenario

Download the ChromeDriver executable for Chrome version 113.
Set the Chrome browser driver executable in the Environment Variable.
Open the Chrome browser having the latest version 115 using Selenium WebDriver.

In this scenario, we will manually set the driver for ChromeDriver version 113 in the environment variable PATH and try to perform Selenium testing on the Chrome browser’s latest version, which is 115.

So ideally, we should get the following warning message in the console output along with SessionNoCreatedException.

Implementation

Chrome browser version 115 is currently installed on the local machine.

To test this scenario, we need to download the ChromeDriver executable for version 113. So there is a mismatch between the Chrome browser and the ChromeDriver versions. Here, we will be downloading the ChromeDriver.exe for Windows platform.

Once the ChromeDrive.exe is downloaded, let’s set the ChromeDriver executable path in the Environment variable.

Navigate to System Properties and open the Environment Variables window by clicking the Environment Variables button.

Select the Path variable and click on the Edit button.

Add the ChromeDriver.exe’s path in it.

Click on the OK button and close the Environment Variable window.

Perform browser automation testing platform on the most powerful cloud infrastructure. Leverage LambdaTest automation testing for faster, reliable and scalable experience on cloud.

The following automation test scripts are written in the SeleniumWebDriverManagerTest class.

@Test
public void testOnChromeBySettingEnvVariablePath() {
   WebDriver driver = new ChromeDriver();
   driver.get("https://ecommerce-playground.lambdatest.io/");

   driver.quit();
}

testOnChromeBySettingEnvVariablePath() will open the Chrome browser using the ChromeDriver.exe set in the PATH variable, navigate to the LambdaTest eCommerce website and close the browser.

Note: This test will not run successfully and will fail, throwing the SessionNotCreatedException with a warning that the ChromeDriver.exe is incompatible.

Test Execution

The following test block is added in the testng.xml file that will help execute the test.

Here is the screenshot of the test execution showing the test failure with the warning and NoSessionCreatedException.

**Introduction to Chrome for Testing

**With the Selenium Manager’s 4.11.0 release, a major new feature, “Automated Browser Management,” has been introduced that manages the Chrome browser as well as its respective browser drivers for version 113 and above. This has been made possible due to the Chrome team’s latest release — Chrome for Testing (CfT).

The Google Chrome team recently announced the release of Chrome for Testing(CfT). It is a new flavor of Chrome that specifically targets web application testing and is created initially for web browser automation testing. It is not recommended for daily browsing.

A regular Chrome release is evergreen, meaning the browsers are automatically upgraded to future versions. However, Chrome for Testing is not evergreen. This is the key difference between a normal Chrome release and Chrome for Testing.

From Chrome version 114, the ChromeDriver team has stopped publishing the ChromeDriver releases and metadata on their traditional ChromeDriver download repository.

The portable binary releases from ChromeDriver version 115 for Chrome for Testing for Windows, Linux, and macOS for its different versions, including Stable, Beta, Dev, and Canary, can be programmatically checked using the CfT JSON endpoints.

**Automated Browser Management with Selenium Manager using Chrome for Testing

**In the earlier section of this blog, we learned how Selenium Manager automates driver management for modern browsers like Chrome, Firefox, and Edge. With the introduction of Chrome for Testing, Selenium Manager also implements automated browser management for Chrome browsers.

Below is the pictorial representation of Selenium Manager’s automated browser management for Chrome for Testing.

Selenium Manager now downloads the Chrome browser in case Chrome is not installed on the machine where automation tests are run. When a web automation test is targeted to run on Chrome browser’s latest version or any other specified version (v113 and above), use the following statement in the code:

Webdriver driver = new ChromeDriver();

Selenium Manager will perform the following steps to perform automated browser management using Chrome for Testing.

*Step 1 — Chrome browser version discovery

**Selenium Manager checks the Chrome browser version installed on the machine where the web automation tests are executed. It uses the command *google-chrome –version under the hood to check for the browser version.

*Step 2 — Chrome Driver version discovery

**On getting the browser version from Step 1, the *ChromeDriver version is identified programmatically using CfT JSON endpoints.

*Step 3 — Chrome Driver download

**Using the *ChromeDriver URL obtained from Step 2, the ChromeDriver artifact is downloaded. This artifact is uncompressed and stored locally.

*Step 4 — Chrome browser download CfT

**This step is a newly introduced feature in Selenium WebDriver from version 4.11.0. In this step, if the version of the Chrome browser is not installed on the machine on which the automated tests need to be executed, then the current stable CfT release is discovered, downloaded, and cached. In addition to the stable version, Selenium Manager also allows downloading the older version till v113.

In case the Chrome browser version specified in the test is lower than “113”, it will throw *NoSuchDriverException with the following error (here, the Chrome browser version was provided as “112” in the tests):

In addition to the fixed browser versions, like 113, 114, etc., the following Chrome for Testing browser version labels can also be specified in the automated tests.

*Step 5 — Chrome driver cache

**All the Chrome for Testing releases are saved to the local cache *(~/.cache/selenium/chrome). This helps in re-using the same browser driver and executing the tests again if the tests are required to be run on the same browser/driver in the future.

Perform browser on the most powerful testing automation cloud infrastructure. Leverage LambdaTest automation testing for faster, reliable and scalable experience on cloud.

Running Tests on Chrome browser using Chrome for Testing with Selenium Manager

**Let’s now get our hands dirty by checking out the actual working of automated browser management using Chrome for Testing using Selenium Manager.

**Test Scenario 1

Set the Chrome browser version to 113 (not installed on the machine).
Open Chrome browser.
Navigate to the LambdaTest eCommerce playground website.

**Implementation

**In this scenario, we will check that the Chrome browser(v113) that is targeted to run a web automated test is not installed on the machine where tests will be executed, so Selenium Manager should install and cache the Chrome browser(v113) using Chrome for Testing and run the test.

The following automation tests are written in the SeleniumWebDriverManagerTest class.

private WebDriver driver;

@Test
public void testOnChromeOldVersionWithSeleniumManager() {
final ChromeOptions options = new ChromeOptions();
options.setBrowserVersion("113");
this.driver = new ChromeDriver(options);
this.driver.get("https://ecommerce-playground.lambdatest.io/");
assertEquals(this.driver.getTitle(), "Your Store");
}

@AfterMethod(alwaysRun = true)
public void tearDown() {
this.driver.quit();
}
}

The testOnChromeOldVersionWithSeleniumManager() is created for testing this scenario. Using ChromeOptions() class, we will set the Chrome browser version to 113 to run the tests. Once the browser is opened, it will navigate to LambdaTest’s eCommerce website and perform assertions to match the title.

Test Execution

Let’s create a testng.xml file and execute the test.

When the test is run, Selenium Manager checks for the Chrome browser version. As v113 was not installed on the machine, it downloads and saves the browser binary and its respective driver(v113) in the ~/.cache/selenium/chrome folder on the machine. Finally, the Chrome browser with v113 was run as specified in the test.

Here is the screenshot of the test execution showing the test passing successfully.

With this, it can be noted that using Selenium’s latest version, 4.11.0, we can run automated tests on any Chrome browser version starting from 113 and above, even if it is not installed on the machine. Using Chrome for Testing’s JSON Endpoints, the respective Chrome browser version will be downloaded and saved in the cache for running automated tests.

Test Scenario 2

In this scenario, we will be running the tests by setting the different Chrome versions using the Chrome for Testing version labels, namely, stable, beta, dev, and canary, which is supported in the Selenium WebDriver’s latest release version, 4.11.0

Set the Chrome browser version using the following labels in the setBrowserVersion method of ChromeOptions class.

a. stable

b. beta

c. dev

d. canary
Open Chrome browser.
Navigate to the LambdaTest eCommerce playground website.

Implementation

We will use the @DataProvider annotation of TestNG by parameterizing the browser version. This will help in handling all 4 test cases of running tests on stable (v115.0.5790.170), beta(v116.0.5845.62), dev(117.0.5927.0), and canary(117.0.5936.0) in a single automation test.

The following two methods browserVersions() and testChromeVersionsWithSeleniumManager() are created in the SeleniumWebDriverManagerTests class.

private WebDriver driver;
@DataProvider
public Iterator<Object[]> browserVersions() {
final List<Object[]> versions = new ArrayList<>();
versions.add(new Object[]{"stable"});
versions.add(new Object[]{"beta"});
versions.add(new Object[]{"dev"});
versions.add(new Object[]{"canary"});
return versions.iterator();
}

@Test(dataProvider = "browserVersions")
public void testChromeVersionsWithSeleniumManager(final String browserVersion) throws InterruptedException {
final ChromeOptions options = new ChromeOptions();
options.setBrowserVersion(browserVersion);
this.driver = new ChromeDriver(options);

this.driver.get("https://ecommerce-playground.lambdatest.io/");

assertEquals(this.driver.getTitle(), "Your Store");
}

@AfterMethod(alwaysRun = true)
public void tearDown() {
this.driver.quit();
}

browserVersions() method is created to pass the parameterized browser version values using the @DataProvider annotation.

testChromeVersionsWithSeleniumManager() test is created to run the automation tests on different versions of Chrome browser. The @DataProvider annotation will help iterate and pass on the browser version values in the setBrowserVersion() method of ChromeOptions class that is finally used for running the ChromeDriver. It will run the tests four times for four different versions of browsers as specified in the browserVersions() method.

Test Execution

The following test block is added in the testng.xml that will execute the test for this scenario.

The test on the stable version of Chrome runs successfully. However, the tests for beta, dev, and canary versions failed, for which an issue has already been reported on Selenium’s GitHub Repo.

The Chrome for Testing release binaries are saved to ~/.cache/selenium/chrome folder.

Below are the details of the test execution showing the test failures for the test run on beta, dev, and canary versions.

Error displayed in the logs for beta, dev, and canary versions

Test Execution (Chrome — 113.0, Test Status — Pass)

Test Execution (Chrome — beta(v116.0.5845.62), Test Status — Fail)

When the tests for the beta, dev, and canary versions run, the Chrome browser icon is displayed with a Test label on it.

Test Execution (Chrome — dev(v117.0.5927.0), Test Status — Fail)

Test Execution (Chrome — canary(v117.0.5930.0), Test Status — Failed)

This marks the completion of this scenario where we checked by running the tests using Chrome for Testing browser versions stable, beta, dev, and canary.

Test Scenario 3

In this scenario, we will be checking that when the Chrome browser version is set to 112 for running the automation tests and the ChromeDriver executable is not provided.

Here, Selenium Manager should not be automatically managing the Chrome browser and ChromeDriver for version 112 as Chrome for Testing has been introduced for Chrome version 113 and above, so Selenium Manager won’t be able to find the download endpoints for 112 and throw an error.

Set the Chrome browser version to 112 (not installed on the local machine).
Open Chrome browser.
Navigate to the LambdaTest eCommerce playground website.

Implementation

Let’s run a web automation test by setting the Chrome browser version to 112. However, in this scenario, the local Chrome browser installed has version 115. This test should fail as Chrome for Testing is available for versions 113 and above.

The following test method, testOnChomeOldVersion112(), is available in the SeleniumWebDriverManagerTest class

@Test
public void testOnChromeOldVersion112() {
final ChromeOptions options = new ChromeOptions();
options.setBrowserVersion("112");

this.driver = new ChromeDriver(options);
this.driver.get("https://ecommerce-playground.lambdatest.io/");

assertEquals(this.driver.getTitle(), "Your Store");
}

This test will set the browser version to 112 using the setBrowserVersion() method of ChromeOptions class, navigate to the LambdaTest eCommerce playground website and perform an assertion of the page title.

Test Execution

Here, the testng.xml file has been updated to run the test.

The test should fail with the following error: Chrome for Testing was introduced for Chrome version 113, and the current version of the installed browser on the local machine is 115.

Here is the screenshot of the test execution:

This shows that Chrome for Testing is only available with versions 113 and above and can not be used with versions below it.

This tutorial dive deep into web testing to help you understand its life cycle, elements, angles, the role of automation, and more.

Final Thoughts

With the release of Selenium WebDriver’s version 4.11.0, it has proved to be more powerful with the latest features of Selenium Manager, which includes the batteries and allows it to run the browsers seamlessly, performing the discovery, download, and cache of the browser drivers.

The release of Chrome for Testing (CfT) by the Chrome team has made the automation test engineer’s life easier as it will also allow testing the web application on Chrome’s upcoming versions like beta, dev, and canary

Also, testers don’t have to worry about the Chrome browser installation as well on the local machine as going ahead for version 113 and above, Selenium Manager will automatically perform the automated browser management allowing seamless execution of web automation tests.

With the ease of directly invoking browsers using Selenium Manager, it was a hassle-free experience to use Selenium WebDriver’s latest version, 4.11.0. I recommend using Selenium WebDriver’s latest version, which provides automated drivers and Chrome browser management and helps us perform automation testing seamlessly.

Thread.sleep() Method in Java – Complete Tutorial With Example

Faisalkhatri123 — Thu, 27 Jul 2023 07:29:45 +0000

Thread.sleep() Method in Java — Complete Tutorial With Example

Steve (a fresher) recently joined our team as a Test Engineer. He was passionate and eager to learn new techniques and technologies and gain expertise in software testing. We were working on an application that eased the customers’ pain of making offline medical payments by standing in queues to bring it all at their fingertips and make the payments online.

It was a web application that helped customers to make payments easily using their Debit and Credit Cards. It had an intuitive interface that could be easily learned to use.

As it was a web application, our team agreed to use Selenium WebDriver with Java, as most of the application was written using Java. Steve was given one task of automating the payment page. It had some fields related to the Credit/Debit Card numbers, CVV, and some fields to accept user details like First Name, Last Name, Address, etc.

It was an easy task; however, since Steve was new to the test automation field, he could automate most of the stuff. However, he struggled with one automation test case where he had to click on the Continue button of a pop-up message after entering the card details for making a payment. As he could not find a solution, he approached me with the query, and we decided to debug the test further for the failure.

We thought it might be an issue related to the incorrect locator of the Continue button. Locators in Selenium play a significant role in interacting with the web elements. Initially, XPath was used to locate the Continue button, so we changed it to CSS Selector as it is faster and simpler than XPath. However, the test was still unable to click on the Continue button.

To debug the issue, we decided to use Thread.sleep() in the code to pause the code for 3 seconds and place it above the code statement where we were clicking on the Continue button. Voila, the test ran successfully!!

When we investigated the problem further, we found that it took some time for the pop-up to appear on the screen. However, by the time the pop-up appeared, the code had passed the lines where it needed to click on the Continue button. Due to this, the test failed. Many test automation engineers might have faced a similar issue as well. The learnings of this blog on using Thread.sleep() in Java can be useful in resolving such issues.

In this Selenium Java tutorial, we will be talking about Thread.sleep() in Java to pause the code execution for some time and will move towards the best practices of using Selenium’s Implicit, Explicit and Fluent Waits in the code for saving the time in test automation code execution.

Learn the essential concepts, techniques, and strategies for high-quality software through effective Software Quality Assurance. This guide covers its importance, benefits, practical tips, and best practices

What is Thread.sleep()?

Thread class is present in java.lang package and contains the sleep() method in it.

Thread.sleep() stops the execution of a program in the current thread for a certain time as per the duration specified as a parameter.

This is a blocking wait unless any other thread generates an interrupt. So, when it comes to using T*hread.sleep()* in test automation, it can have huge repercussions if the delay is high.

The sleep() method does not return any value as the method is void. It throws an InterruptedException in case any other thread interrupts the current thread.

The following image explains the life cycle of a thread –

When a thread is created, it is in a New state meaning its code is yet to be run and is not started to execute.

Next, it moves to a Runnable instance, which means the code is in the state to run and can be executed at any time.

Running instance is where the code execution starts, after which the timed wait may be called for blocking or making the program wait for a fixed time duration, and the program will return to a runnable/running state after the duration has passed. For example, the sleep() method is called in Thread to make the thread wait for a timed duration.

Finally, the thread is Terminated either due to the program execution being complete or any error occurred, causing the program to exit abruptly. For example, an unhandled exception occurred.

There are two overloaded sleep() methods in the Thread class as follows:

sleep(long millis)
sleep(long millis, int nanos)

Discover the ins and outs of UX testing with this comprehensive guide. Explore various testing methods, tools, and best practices for measuring success

sleep(long millis)

This method accepts one parameter (i.e., duration of time in milliseconds). It throws an InterruptedException if any other thread interrupts the current thread.

Another exception this method can throw is an IllegalArgumentException when the value of milliseconds supplied in the parameter is negative or not in the range from 0–999999.

Example

The following code shows a simple implementation of how to use Thread.sleep() to pause your automation tests for debugging purposes.

import java.lang.Thread;

@Test
public void testThreadSleep() throws InterruptedException {
WebDriver driver = new ChromeDriver();
driver.get("https://ecommerce-playground.lambdatest.io/");

Thread.sleep(3000);
String title = driver.getTitle();

System.out.println(title);
driver.quit();
}

The above snippet will create a new instance of ChromeDriver and navigate to the LambdaTest eCommerce playground. It will halt the test execution using Thread.sleep for 3 seconds(3000 milliseconds = 3 seconds). It will get the web page’s title and print it in the console. Finally, the quit() method of Selenium is called to quit the driver instance gracefully.

Test Execution

On executing the tests, the page title “Your Store” gets printed in the console. The total time taken to execute the tests is 10 seconds 561 ms, which includes the 3000 milliseconds (3 seconds) of Thread.sleep() method.

sleep(long millis, int nanos)

This is an overloaded version of the sleep() method we discussed in the earlier section of this blog on using Thread.sleep() in Java. It accepts two parameters, the first duration of time in milliseconds, and the second is the time in nanoseconds that is provided as additional time for the thread to sleep.

It throws an InterruptedException in case any other thread interrupts the current thread. IllegalArgumentException is thrown when the values in any of the two parameters are provided as negative or are not in the range 0–999999.

Example

The following snippet shows a simple implementation of how to use Thread.sleep() to pause your automation tests for debugging purposes.

import java.lang.Thread;

@Test
public void testThreadSleep() throws InterruptedException {
WebDriver driver = new ChromeDriver();
driver.get("https://ecommerce-playground.lambdatest.io/");

Thread.sleep(3000);
String title = driver.getTitle();

System.out.println(title);
driver.quit();
}

The above snippet creates a new instance of *ChromeDriver*and navigates to the eCommerce playground. The execution is halted for 3000 milliseconds and 2 nanoseconds.

Next, it will fetch the current URL using Selenium’s getCurrentUrl() method and print the URL’s text in the console. Finally, Selenium’s quit() method will be called to quit the driver gracefully.

Test Execution

Here is the screenshot from IntelliJ that shows the test execution.

The total time taken to execute tests is 11 seconds 161 ms, including the time duration (3000 milliseconds and 2000 nanoseconds) added in the Thread.sleep() method.

Explore our comprehensive guide on GUI Testing, uncovering its vital role in software development. Learn about its different types, best practices, and steps for effective implementation to enhance your software’s user interaction.

Thread.sleep() example in a multi-threaded program

In the previous examples, we used Thread.sleep() in a single-threaded program, meaning only one thread was Running.

Let’s see how Thread.sleep() can be used in a multi-threaded program.

FileName: ThreadLocalExample.java

public class ThreadLocalExample implements Runnable {

private final ThreadLocal<Integer> threadLocal = new ThreadLocal<Integer>();

@Override
public void run() {
final long startTime = System.currentTimeMillis();
this.threadLocal.set((int) (Math.random() * 40D));
try {
Thread.sleep(2000);

} catch (final InterruptedException e) {
throw new RuntimeException(e);

}
final long endTime = System.currentTimeMillis();
final NumberFormat formatter = new DecimalFormat("#0.00000");
System.out.println("Thread Id - " + this.threadLocal.get() + " Execution time is " + formatter.format((endTime - startTime) / 1000d) + " seconds" + "\n");
}

public static void main(final String[] args) {
final ThreadLocalExample threadLocalExample = new ThreadLocalExample();
final Thread t1 = new Thread(threadLocalExample);
final Thread t2 = new Thread(threadLocalExample);
t1.start();
t2.start();
}
}

In this example, ThreadLocalExample class implements a Runnable interface that helps execute the thread. Runnable interface’s run() method is implemented in this class that sets the ThreadLocal value and gets the program’s start and end time in milliseconds.

Thread.sleep() blocks the thread for 2000 milliseconds (i.e., 2 seconds). Finally, the total time to run the program is printed in decimals.

Test Execution

The following screenshot from IntelliJ shows that the total time to execute the program was 2.00500 seconds. This includes 2 seconds blocked by Thread.sleep().

Why is using Thread.sleep() discouraged?

Thread.sleep() is a blocking call that halts the execution for some time and helps the automation tests to proceed successfully, with all the respective elements getting loaded for interaction.

Problem 1

Imagine putting Thread.sleep() in Java with 5 seconds stop time at 5 different places in the test. We are putting in 25 seconds of hard waits in the test.

Thread.sleep() once set is set for the session’s lifetime.

Problem 2

Next problem we may face with Thread.sleep() in Java is that we might need to change the time duration if the time required for locating the element or performing action over the element keeps changing. For example, while running the test for the first time, the 3 seconds wait time worked fine with the sleep() method to locate an element and perform a click on it. However, in the next run, tests failed, and the duration was required to increase to 5 seconds.

This happens as fixed time duration is a flaky approach as locating elements also depends on external factors like rendering time, internet speeds, etc., some of which are not under our control. Flaky internet speeds can also cause the tests to fail even after adding Thread.sleep().

Problem 3

Another problem is the repetitive code we would require to add by adding the Thread.sleep() statement multiple times in the code. The statement must be applied before locating the web element or performing an action. In case multiple elements need some wait, we will have to add Thread.sleep() statements multiple times in the code, and there will be a time when our code will be mostly covered with Thread.sleep() statements.

We can use Selenium’s Waits to overcome this problem of hard waits. In the next section of this blog on the Thread.sleep() in Java, let’s study different types of Selenium Waits and how to implement them in the tests.

Looking to manage your tests more efficiently? In this blog, explore a variety of test case management tools and select the one that suits your team’s needs:

Selenium Waits

Selenium Waits are the best replacement for Thread.sleep() as they help execute the automated UI tests seamlessly on the browser. The issues that may arise due to variations in time lag can be easily handled using Selenium Waits. There are three types of Waits in Selenium WebDriver:

Implicit Wait
Explicit Wait
Fluent Wait

Implicit Wait in Selenium WebDriver

Implicit wait is useful when certain elements on the web page are not available immediately and need some time to load. This wait polls the DOM for a certain duration as specified in the wait. By default, implicit wait is set to 0 and is disabled. Once set in tests, it is set for the session’s life.

implicitlyWait() method is available in the timeouts() interface in Selenium WebDriver. It accepts one parameter, that is, duration of time. This parameter can be supplied using the Duration class from java.time package.

Once implicit wait is set in the test, it is non-blocking and does not wait for the entire time duration like Thread.sleep(). This saves 5 seconds, whereas Thread.sleep() will halt the code execution in the current thread for a full 10 seconds and then only move to the next line.

If the web element is not found in the time duration set for the implicit wait, NoSuchElementException will be thrown. You can learn more about it through this blog on Common Selenium Exceptions.

Syntax

Code Example

driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));

Explicit Wait in Selenium WebDriver

Explicit wait allows the test to wait for a certain time until the expected condition as specified in wait is met. It is applied for a single web element to load, unlike implicit wait, which applies to all the elements on the web page.

Applying explicit wait is non-blocking and does not wait for the entire session life cycle like Thread.sleep().

When the expected condition is not met within the specified time, explicit wait throws TimeoutException.

Syntax

For setting the explicit wait, we first need to instantiate the WebDriverWait class. This class needs an instance of WebDriver and time duration as constructor values. The ExpectedConditions can be set next by using the until() method.

Here is the list of some commonly used ExpectedConditions in explicit wait:

Expected Condition	Description
visibilityOfElementLocated(By locator)	This condition checks that the element is present in the DOM and visible. This condition expects a By locator as a parameter for the method.
visibilityOf(WebElement element)	This condition checks that the element is present in the DOM and is visible. It expects a WebElement as a parameter for the method.
alertIsPresent()	This condition checks if the alert is present.
elementToBeClickable(By locator)	This condition checks that the element is present and visible and can be clicked. It expects a By locator as a parameter for the method.
elementToBeClickable(WebElement element)	This condition checks that the element is present, visible, and can be clicked. It expects a WebElement as a parameter for the method.
presenceOfElementLocated(By locator)	This condition checks that the element is present on the page using its By locator.
textToBePresentInElement(WebElement element, final String text)	This condition checks that the text is present in the WebElement.
textToBePresentInElementLocated(By locator, final String text)	This condition checks that the text in the WebElement matches the given locator.

You can learn more about it through this blog on ExpectedConditions in Selenium.

The ultimate guide to software testing metrics: definition, types, and examples explained for informed decisions. Enhance your testing process now.

Code Example

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(5));
WebElement checkoutBtn = driver().findElement(By.cssSelector("#check"));
wait.until(ExpectedConditions.visibilityOf(checkoutBtn));

In the example above, the Checkout button on the web page is located using explicit wait. First, the WebDriverWait class is instantiated, providing the driver instance and time duration for the explicit wait. Next, the Checkout button is located and stored as a WebElement. Finally, the expected condition is written to wait until the Checkout button is visible.

As per Selenium’s best practice, it is recommended not to mix the implicit and explicit waits as it might lead to unpredictable wait times. For example, if an implicit wait of 10 seconds is

provided and an explicit wait of 15 seconds is also used, it might cause a timeout to occur after 20 seconds.

Fluent Wait in Selenium WebDriver

Fluent wait allows you to wait for a maximum amount of time for a condition. It also allows to add the following two additional parameters to wait for that are not allowed in implicit and explicit waits –

Polling Frequency
Ignore Exceptions

Polling Frequency

It sets the frequency in which the condition should be checked. For example, the total timeout can be set for 10 seconds with a polling frequency of 2 seconds, i.e., the condition will be checked for 10 seconds in every 2 seconds frequency.

Ignore Exceptions

With fluent waits, we can also set it to ignore the exception that can appear while waiting for the condition. For example, the total timeout can be set to 10 seconds polling every 2 seconds and ignoring “NoSuchElementException”.

Note: If the fluent wait condition is not fulfilled within the specified time, it will throw TimeoutException.

Syntax

For setting fluent wait, we need to use the Wait interface and instantiate an instance of FluentWait class. After instantiating the FluentWait class, we can chain its following methods:

withTimeout(): Accepts the total time for which the wait needs to be implemented.
pollingEvery(): Accepts the polling frequency time duration.
ignoring(): Provides the exception name, which the fluent wait needs to ignore while waiting for the condition to be fulfilled.

Code Example

public String successMessageText() {
Wait<WebDriver> wait = new FluentWait<>(driver)
.withTimeout(Duration.ofSeconds(10))
.pollingEvery(Duration.ofSeconds(2))
.ignoring(NoSuchElementException.class);


WebElement successMessage = wait.until(driver -> notificationPopUp().findElement(By.tagName("p")));
return successMessage.getText();

In the above code example, a fluent wait has been implemented for 10 seconds that will be polling at a frequency of 2 seconds ignoring NoSuchElementException. This fluent wait will be used for locating the successMessage text from a web element, and finally, the text will be returned in String format.

Let’s now delve into coding and check out how to use Thread.Sleep() in Java. We will also check out how to use implicit, explicit, and fluent waits using Selenium WebDriver.

This tutorial focuses on mobile ui testing, its significance, benefits, strategies, challenges, and best practices.

How to use Thread.sleep(), Implicit Wait, Explicit Wait, and Fluent Waits?

Before I take you on the tour of Thread.sleep() in Java and Selenium Waits, let’s first discuss the Application Under Test (AUT), the tools used, and the test automation strategy.

Application Under Test:

We will use LambdaTest’s eCommerce playground to demo Thread.sleep() in Java and the different Selenium Waits.

Tools/Language used for running tests

Following tools/language has been used in writing and running the tests:

Programming Language: Java
Mobile App Automation Tool: Selenium WebDriver (Version 4.10.0)
Test Runner: TestNG (Version 7.8.0)
Build Tool: Maven
Cloud Platform to run the tests: LambdaTest.

Test Scenario

Launch the LambdaTest’s eCommerce playground.
Search for a product using the search box on the Home Screen.
On the product page, hover the mouse on the product.
Click on the Add to Cart button.
Click on the Checkout button on the pop-up message displayed.

We must wait for the pop-up to appear and get the success message text. Next, we need to click on the Checkout button to checkout the product from the cart.

In the demo, we will first use the Thread.sleep() in Java to pause the test execution and then will use the explicit and fluent waits to replace Thread.sleep() and remove the hard waits from the test.

Before we move to product checkout, we need to perform two steps: logging in to the website and searching for a product, and finally, adding the product to the cart.

The following screen will be used to log in to the website.

The following screen will be used to search for the product.

As this blog on Java automation testing focuses more on Thread.sleep() in Java and Selenium Waits, I will provide a minimal explanation of the two steps, i.e., logging in to the website and searching for a product.

Implementation

The project has been created using Maven, and the following image shows the structure of the project.

Once the project is built, we need to add the dependencies for Selenium WebDriver and TestNG in the pom.xml. I preferably follow the best practice of including all the dependencies in the properties tab block in the pom.xml file. You can find out the details in the following screenshots:

Dependencies in pom.xml

Properties block in pom.xml

FileName — pom.xml


<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>io.github.mfaisalkhatri</groupId>
<artifactId>selenium-wait-demo</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>

<name>selenium-wait-demo</name>
<url>http://maven.apache.org</url>

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<selenium.java.version>4.10.0</selenium.java.version>
<testng.version>7.8.0</testng.version>
<maven.compiler.version>3.11.0</maven.compiler.version>
<surefire-version>3.1.2</surefire-version>
<java.release.version>17</java.release.version>
<maven.source.encoding>UTF-8</maven.source.encoding>
<suite-xml>testng.xml</suite-xml>
<argLine>-Dfile.encoding=UTF-8 -Xdebug -Xnoagent</argLine>
</properties>

<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium.java.version}</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.testng/testng -->
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>${testng.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.version}</version>
<configuration>
<release>${java.release.version}</release>
<encoding>${maven.source.encoding}</encoding>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire-version}</version>
<executions>
<execution>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
<properties>
<property>
<name>usedefaultlisteners</name>
<value>false</value>
</property>
</properties>
<suiteXmlFiles>
<suiteXmlFile>${suite-xml}</suiteXmlFile>
</suiteXmlFiles>
<argLine>${argLine}</argLine>
</configuration>
</plugin>
</plugins>
</build>
</project>

The tests will be run on the Google Chrome browser on LambdaTest’s Cloud grid using Windows 10 Operating System. To set the browser, OS, and its respective version, we can use the LambdaTest Capabilities Generator.

Discover the ins and outs of UX testing with this comprehensive guide. Explore various testing methods, tools, and best practices for measuring success

Implementing Implicit Wait in Selenium

Once we know what capabilities we need to set in the cloud, we will create a DriverManager class that will help set up the browser in the cloud.

Following is the code implementation of the DriverManager class.

FileName — DriverManager.class


public class DriverManager {

WebDriver driver;
private static final String LT_USERNAME = System.getProperty("LT_USERNAME");
private static final String LT_ACCESS_KEY = System.getProperty("LT_ACCESS_KEY");
private static final String GRID_URL = "@hub.lambdatest.com/wd/hub";

public void createChromeDriverInCloud() {
final ChromeOptions browserOptions = new ChromeOptions();
browserOptions.setPlatformName("Windows 10");
browserOptions.setBrowserVersion("114.0");
final HashMap<String, Object> ltOptions = new HashMap<>();
ltOptions.put("username", LT_USERNAME);
ltOptions.put("accessKey", LT_ACCESS_KEY);
ltOptions.put("resolution", "2560x1440");
ltOptions.put("selenium_version", "4.0.0");
ltOptions.put("build", "LambdaTest ECommerce Playground Build");
ltOptions.put("name", "LambdaTest ECommerce Playground Tests");
ltOptions.put("w3c", true);
ltOptions.put("plugin", "java-testNG");
browserOptions.setCapability("LT:Options", ltOptions);
try {
driver = new RemoteWebDriver(new URL(format("https://{0}:{1}{2}", LT_USERNAME, LT_ACCESS_KEY, GRID_URL)), browserOptions);
} catch (MalformedURLException e) {
throw new Error("RemoteDriver's URL not set correctly!");
}
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
}

public void createChromeDriverLocal() {
driver = new ChromeDriver();
}

public WebDriver getDriver() {
return this.driver;
}

public void quitDriver() {
driver.quit();
}
}

Code Walkthrough

The first two variables declared in the class will help us read LambdaTest’s cloud login credentials, i.e., Username and AccessKey, on runtime, as these are secret variables and can not be declared as hard-coded values in the code. These values will be set in the createChromeDriverInCloud() method.

createChromeDriverInCloud() method in DriverManager class

This method will create a new Chrome browser instance on LambdaTest Cloud Grid. After the driver is set, the implicit wait will be set for 10 seconds using the following statement in the above method –

Implementing the Test Scenarios

Scenario 1

The first scenario we need to implement is the Login Scenario. This will help you log in to the website and perform further actions of adding the product to the cart and checking out easily. The code snippet of the testLogin() method is available in the LambdaTestEcommerceTests class.

LambdaTestEcommerceTests class

public class LambdaTestEcommerceTests extends BaseTest{

@Test
public void testLogin() {
HomePage homePage = new HomePage(driverManager.getDriver());
homePage.navigateToLoginPage();
LoginPage loginPage = new LoginPage(driverManager.getDriver());
loginPage.login(System.getProperty("username"),System.getProperty("password"));
assertEquals(loginPage.getMyAccountPageHeader(),"My Account");
}
}

The testLogin() method will help in navigating to the Login Page and allow performing the login to the LambdaTest eCommerce website. The Username and Password for login will be supplied on run time. Finally, assertions will be performed to check that the page header should be “My Account” after successful login.

Login link on Home Page

Login Page

Account Page after successful login

Below is the code snippet from the HomePage class that has all the Page Objects for Home Page.

The Page Object Model helps segregate the page objects with the actions, enabling easy code maintenance. It is a popular design pattern used in test automation to enhance the maintainability and reusability of test code, particularly in web-based applications. It achieves this by segregating the web elements on a page from the test actions performed on those elements.

public class HomePage {
WebDriver driver;

public HomePage(WebDriver driver) {
this.driver = driver;
}

private WebElement searchField() {
return driver.findElement(By.name("search"));
}

private WebElement searchBtn() {
return driver.findElement(By.cssSelector("button[type='submit'][class='type-text']"));
}

public void searchProduct(String productName) {
searchField().clear();
searchField().sendKeys(productName);
searchBtn().click();
}

public String searchResultText() {
return driver.findElement(By.cssSelector("div.product-layout:nth-child(1) div:nth-child(1) h4 > a.text-ellipsis-2")).getText();
}

public void navigateToLoginPage() {
driver.findElement(By.linkText("My account"))
.click();
driver.findElement(By.linkText("Login")).click();
}
}

The BaseTest class is extended by LambdaTestEcommerceTests class. The BaseTest class has two methods, namely, testSetup() and tearDown(). The testSetup() method helps instantiate the DriverManager class and calls the createChromeDriverInCloud() to run the tests on the Chrome browser in the LambdaTest cloud grid. The tearDown() method helps in gracefully quitting the WebDriver after the tests are run.

public class BaseTest {

DriverManager driverManager;

@BeforeTest(alwaysRun = true)
public void testSetup() {
driverManager = new DriverManager();
driverManager.createChromeDriverInCloud();
driverManager.getDriver().get("https://ecommerce-playground.lambdatest.io/");
}

@AfterTest(alwaysRun = true)
public void tearDown() {
driverManager.quitDriver();
}
}

Scenario 2

The next scenario is to search for a product from the Home Page after logging in to the website.

Search products from the Home Page

Search results

Following is the test to search for the product.

@Test
public void testSearchProduct() {
String productName = "Palm Treo Pro";
HomePage homePage = new HomePage(driverManager.getDriver());
homePage.searchProduct(productName);
assertEquals(homePage.searchResultText(), productName);
}

“Palm Treo Pro” is the product that will be searched from the website’s Home Page; after the results appear, the text will be asserted against it.

The following method — searchProduct() from the HomePage class will help us search the product, and the searchresultText() method will help us verify the search result text.

Looking to manage your tests more efficiently? In this blog, explore a variety of test case management tools and select the one that suits your team’s needs.

Scenario 3

In this scenario, the add product to the cart step will be automated. To add products to the cart, we need to hover on the product and click on the “add to cart” icon after the hovering toolbar appears.

Next, a pop-up message will appear showing the success message for adding the product to the cart with the Checkout button. We will be asserting the success message and clicking on the Checkout button.

Implementing Thread.sleep() in Selenium

Below code is of the testAddProductToCart() method that performs all the actions mentioned in the earlier paragraph.

testAddProductToCart() in LambdaTestEcommerceTests class

@Test
public void testAddProductToCart() {
ProductPage productPage = new ProductPage(driverManager.getDriver());
productPage.addPalmTreoCameraLensToCart();
final String expectedMessage = "{0}\n{1}\n{2}\n{3}\n{4}";
assertEquals(productPage.successMessageText(), format(expectedMessage, "Success: You have added", "Palm Treo Pro", "to your",
"shopping cart", "!"));
productPage.checkoutProduct();
}

ProductPage class is created for storing the product page web elements and interacting with them.

public class ProductPage {
WebDriver driver;

public ProductPage(WebDriver driver) {
this.driver = driver;
}

public void addPalmTreoCameraLensToCart() {
final Actions actions = new Actions(driver);
actions.moveToElement(palmTreoCameraLens())
.pause(200)
.moveToElement(addToCartBtn())
.pause(100)
.click()
.perform();
}

public void checkoutProduct() {
checkoutBtn().click();
}

public String successMessageText() {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
return notificationPopUp().findElement(By.tagName("p")).getText();
}

private WebElement addToCartBtn() {
return driver.findElement(By.cssSelector("div.product-action > button.btn.btn-cart.cart-29"));
}

private WebElement checkoutBtn() {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
return notificationPopUp().findElement(By.cssSelector("div.form-row > div:nth-child(2) > a"));
}

private WebElement notificationPopUp() {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
return driver.findElement(By.id("notification-box-top"));
}

private WebElement palmTreoCameraLens() {
return driver.findElement(By.cssSelector(".product-layout"));
}
}

As mentioned earlier, we need to wait for the pop-up notification to appear. The following method notificationPopUp() has Thread.sleep() implemented, which pauses the test for 2 seconds to wait for the notification to appear. In this method, try catch block is used for implementing Thread.sleep() as it is more convenient and helps catch the run time exceptions. Once try catch is implemented, we don’t have to put the words throws InterruptedException in every method that uses this notificationPopUp() method, which has Thread.sleep() in it.

Likewise, Thread.sleep() in Java is used in the successMessageText() method as well, as we need to wait for a success message to appear to get its text.

Similarly, Thread.sleep() in Java pauses the test for locating the Checkout button. Here is the code snippet for the checkoutBtn() method that returns the web element for the checkout button.

Test Execution

Let’s execute the tests using testng.xml by right-clicking on the file and selecting the option Run ...\testng.xml. Here we are using the cloud testing platform, LambdaTest to execute the tests.

LambdaTest is a digital experience cloud platform that lets you perform automation testing at scale on over 3000+ real desktop and mobile browsers. Just like the Thread.sleep() in Java helps you pause test execution for a certain amount of time, running tests on a cloud-based grid will further improve the accuracy of your tests.

The ultimate guide to software testing metrics: definition, types, and examples explained for informed decisions. Enhance your testing process now.

Moreover, running your automated tests in parallel will cut down your test execution time, enabling faster Selenium Java testing to ensure a quality web experience.

To run tests on LambdaTest, we need to enter the following values to execute the tests successfully.

LambdaTest Username
LambdaTest AccessKey
Username of LambdaTest eCommerce Website
Password of LambdaTest eCommerce Website

Username and Password for LambdaTest’s eCommerce Website must be supplied for successfully logging in to the website.

All the values can be supplied using the Edit configuration window and supplying the values as

-DLT_USERNAME=< LambdaTest Username> -DLT_ACCESS_KEY=< LambdaTest Access Key > -Dusername=< Website username for login scenario > -Dpassword=< Website password for login scenario >

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="LambdaTest ecommerce playground website test suite ">
<test name="Search Product tests " >
<classes>
<class name="io.github.mfaisalkhatri.tests.LambdaTestEcommerceTests">
<methods>
<include name="testLogin"/>
<include name="testSearchProduct"/>
<include name="testAddProductToCart"/>
</methods>
</class>
</classes>
</test> <!-- Test -->
</suite> <!-- Suite -->

Screenshot of the test run locally using TestNG in IntelliJ

The total time taken to run the tests can be seen as 37 Seconds and 307 ms, this includes the hard waits we have implemented using Thread.sleep() in the tests.

Let’s now check out how to replace the Thread.sleep() in Java with the explicit and fluent wait to take down the hard waits from the tests and save test execution time.

Implementing Explicit Wait and Fluent Wait in Selenium

There are three methods in the ProductPage class, namely, notificationPopUp(), successMessageText(), and checkoutBtn(), where we have used Thread.sleep() in Java for pausing the test execution. Hence, our tests run smoothly by locating and interacting with the web elements on the Product Page. The Thread.sleep() statements in the code are commented out and have been kept to let us know that it was replaced with explicit and fluent waits in its place, so we know where the hard waits were replaced.

Note: It is not a good practice to keep commented code in the class. Once the code refactoring is done, the commented code should be removed.

Replacing Thread.sleep() with Fluent Wait

Let’s use the fluent wait in the successMessageText() method and replace it with Thread.sleep() in Java.

successMessageText() method in ProductPage class

The fluent wait is defined for 10 seconds polling every 2 seconds ignoring NoSuchElementException. So, if the element is located within 10 seconds, it will move to the next statement of code rather than waiting for a full timeout of 10 seconds to complete. This is the benefit of using Selenium Waits.

Once the web element for successMessage is located using the fluent wait condition. successMessageText() method will return its text.

Note: If the web element is not located within 10 seconds, the fluent wait will throw TimeoutException. The following screenshot shows the TimeoutException printed in the console in IntelliJ.

Replacing Thread.sleep() with Explicit Wait

It is now time to refactor the notificationPopup() method and checkoutBtn() method by removing the Thread.sleep() in Java and replacing it with the explicit wait. As we will be using the explicit wait in two methods, it is better to declare it globally, instantiate it in the class’s constructor, and use it in the respective methods.

This tutorial focuses on mobile ui testing, its significance, benefits, strategies, challenges, and best practices.

Declaring WebDriverWait

Once the instantiation of the WebDriverWait class is done, we are good to use it in the notificationPopUp() and checkoutBtn() methods.

notificationPopUp() method

Using explicit wait, ExpectedCondition — visibilityOfElementLocated() using By locator is used in this method to wait for the notification box to appear.

If the element is not located within the explicit wait timeout of 10 seconds, TimeoutException will be thrown.

The following screenshot shows the TimeoutException printed in the console in IntelliJ.

Coming to the checkoutBtn() method, Thread.sleep() in Java has been replaced by using the ExpectedCondition — visibilityOf() method, where a web element is supplied in its parameter.

Before running the tests, let’s remove the implicit wait that we had added in the createChromeDriverInCloud() method in DriverManager class.

Test Execution

Let’s execute the tests using testng.xml by right-clicking on the file and selecting the option Run ...\testng.xml. As discussed earlier, the following values can be supplied using the Edit configuration window.

Screenshot of the test run locally using TestNG in IntelliJ:

It can be seen that the test execution time has reduced to 24 seconds 707 ms. This shows that Selenium’s explicit and fluent waits are powerful and can help in bringing down the test execution time and also make the code more readable, maintainable, and less flaky.

If you desire to excel in automation testing and improve your Java skills, enrolling in a Selenium Java 101 certification program is an excellent first step toward becoming an automation testing expert. This program will equip you with a robust understanding of using Selenium Java for testing and pave the way for a promising career in this field.

Explore our in-depth guide comparing Protractor vs Selenium to make informed decisions for your test automation needs. Gain valuable insights into the key differences, advantages, and ideal use cases of these widely-used testing frameworks.

Conclusion

Though Thread.sleep() in Java can be used for pausing the test execution for a certain time, it is not a good option to use it in your automation tests as it is a kind of hard wait and can eat up most of the test execution time.

Instead, implicit, explicit, and fluent waits in Selenium WebDriver can be used. These are more advanced waits and can help to pause the test for a certain time to find the locator/wait for the expected condition to be fulfilled and execute the rest of the code as soon as the element is found. It is recommended to refactor your code and use Selenium Waits wherever possible to save the test execution time and keep your tests less flaky.

Happy Testing!!

GPS Geolocation vs IP Geolocation: How To Test Them On Real Devices?

Faisalkhatri123 — Mon, 29 May 2023 05:05:18 +0000

In this era of technological advancements, the widespread adoption of Location Services in mobile phones has paved the way for eCommerce companies to offer personalized products and services through mobile apps.

From showing personalized advertisements to delivering food to our doorstep, Location Services play a vital role and have become important in determining how the product reaches its customers.

Location-based marketing has greatly impacted businesses by raising brand awareness and generating more income with low expenses. It also helps businesses reach specific customer segments with special offers and improve customer satisfaction.

Using GPS geolocation and IP geolocation, businesses can target specific locations and increase the overall engagement for their products. Location-based marketing and advertisements can help convert prospective buyers to actual customers by targeting the local areas specifically. The targeted location marketing for a local product can provide relevant advertisements to the buyers and help defend their product against the marketing competition.

Applications like Google Maps, Uber, DoorDash, etc. use GPS geolocations to know the real location of the user so they can serve them better and accurately show them the correct route, distance, time to travel, time for delivery, etc.

To begin with, let’s first understand different types of Location terminologies. Two terms were re-used on a broader scale for identifying the Location.

GPS Geolocation
IP Geolocation

By the end of this blog, you will learn about GPS geolocation vs IP geolocation and the different related terms, and how to perform manual and automation testing by changing GPS geolocation and IP geolocation.

A comprehensive Exploratory Testing tutorial that covers what Exploratory Testing is, its importance, benefits, and how to perform it with real-time examples.

What is GPS Geolocation?

GPS geolocation is a general term that uses latitude, longitude, and altitude attributes to identify a user’s location. GPS geolocation can be captured using both programming and hardware. On web browsers, GPS geolocation is implemented through Geolocation API, written in JavaScript. This API always works on the client side of the application, like a web browser.

In addition to the Geolocation API, modern smartphones are equipped with GPS receiver chipsets that enable the precise capture of geolocation data. These chipsets play a crucial role in accurately determining the location of smartphone users.

GPS Location — Google Maps shows the current location

GPS geolocation also provides more information related to the user’s current location like country, state, city, street, etc. The identification process involves utilizing geographic coordinates, such as latitude and longitude, obtained through GPS and leveraging these coordinates to pinpoint a precise location.

By harnessing geolocation information, businesses can enhance Smart Navigation capabilities. For instance, they can update their store locations on platforms like Google Maps, enabling users to effortlessly locate and visit their physical stores, fostering convenience and seamless customer experiences.

It can also be used for sending personalized advertisements or push notifications related to promotions or offers based on their location.

The marketing team can also use this information to target potential buyers and convert them into actual customers by performing the data analysis based on geographical location.

The following are the important technical terms used for geolocation testing:

A comprehensive UI testing tutorial that covers what UI testing is, its importance, benefits, and how to perform it with real-time examples.

Geotargeting

IP addresses are the basis of geotargeting. The location of users can then be determined by comparing device IP addresses to factors like the user’s country of residence and postal code.

It refers to serving the users with content and services based on their geographic location. Users may receive push notifications or in-app messages based on their location if they have opted to provide access to the location in the app.

Personalization helps improve customer experience, which is the main advantage of geo-targeted marketing.

Use cases for Geotargeting

eCommerce
Local news and weather

Geofencing

Geofencing is a process of establishing virtual boundaries for devices or products.

It is a location-based service in which RFID (radio-frequency identification) tags, GPS, WiFi, or cellular data are used to track a device’s location near a virtual geographic boundary. Push notifications, automatic emails, text messages, or even targeted social media advertisements can be triggered when a device enters or leaves a Geofence.

In the logistics industry, for example, it is used for security purposes. Hence, the goods/parcels reach their destinations safely with all necessary tracking notifications to the administrators of the service as well as to the end users.

Likewise, it is also used by many fleet owners to track their vehicles and monitor if they are heading to the correct destinations. This is done as a precautionary measure to avoid theft of the vehicles.

Geofencing is also helpful in keeping an eye on the kids. Some smartwatches and apps have this feature, which sends a notification to the parent if their kids move out of the geofence area. This helps parents in monitoring their kids easily and keeping them safe.

Use cases for Geofencing

Google Maps
Food Delivery (e.g., Zomato)

Geotagging

Geotagging adds geographical information to media, such as photos and videos. This information is typically included in the metadata of a media file and can include longitude and latitude coordinates, altitude, etc.

It can be done manually or automatically, providing a great way to store and share location-based data.

Examples include applications like Facebook (check-ins) and Instagram, where users can tag photos at the exact location. Also, search engines like Google use geolocation to search for the accurate image of the places searched for.

Facebook (Geotagging feature)

Use cases for Geotagging

Google Maps

Example of Geotagging — LambdaTest Office image

Example of Geotagging — Microsoft Office image on Google Maps

Geoblocking

Geoblocking is the process of restricting access to certain websites and services based on geolocation.

It is typically implemented by telecommunications companies, websites, and other content providers and intellectual proprietors, often for the sake of copyright restrictions. Geoblocking is done based on the IP address of the user.

Use cases for Geoblocking

OTT Platforms
Online Streaming

In this Ad hoc testing tutorial, let’s deep dive into what Ad hoc testing is, its advantages, disadvantages, types, characteristics, and their best practices.

Localization and Internationalization

Localization and Internationalization are two factors that impact the overall user experience.

Localization refers to adapting a product or service to meet the needs of a particular language, culture, or desired population’s “look and feel”. It helps personalize the product/ services to the native population of specific regions.

On the other hand, internationalization refers to taking the local product to an international level. It is the process of designing a local product to meet users’ needs in many countries.

For example, a website developed locally for Chinese regions may be designed so that it can be translated to English easily so people from international regions can access and use it.

As the end users can get the product/services in their local language, it helps reach the audience through effective advertisement and product use. This allows Sales to gain business within the geographical region for which the application is developed and advertised.

Use cases for Localization and Internationalization

Netflix uses Localization for their website for the Brazilian region

What is IP Geolocation?

IP geolocation is the process of tracking the physical location of an IP address. It uses information gathered by IP address to determine the geographical location of a device on a map.

This information can be used to restrict access to certain regions, improve security, track users’ activities, and customize content. IP geolocation can ideally be found using a website like whatismyip.com

Difference between GPS Geolocation and IP Geolocation

POINTERS	GPS GEOLOCATION	IP GEOLOCATION
Technology	GPS geolocation uses Global Positioning System (GPS) technology to determine the precise location of a device.	IP geolocation uses the IP address of the device to determine its location.
Location Tracking Mechanism	GPS geolocation uses a satellite-based navigation system to provide location information.	IP geolocation uses an IP address, a unique numerical identifier assigned to every device connected to the internet, to provide location information.
Accuracy	It uses a satellite-based navigation system(GPS), so it is more accurate than IP geolocation.	It may be inaccurate as IP addresses can be shared and reassigned.

In this Data driven testing tutorial, let us deep dive into what data driven testing is, its pros & cons, its types, data driven testing in an agile environment, benefits, and their best practices

How to perform GPS and IP Geolocation testing on Real Devices?

In the earlier section of the blog, we discussed terms like Geotargeting, Geofencing, Geoblocking, Localization, etc. All these terms are quite important from the Business and Sales point of view. So, if we are considering any of these points from the mobile application or websites, we need to ensure that we perform thorough testing for the use cases before we proceed to release our mobile application/website to the market.

Consider a mobile application whose major functionalities are based on the user’s current location. Hence, it is important to perform geolocation testing before the application is signed off for release.

In one of my previous projects, we were working on testing a mobile application with scenarios related to Geofencing.

This mobile application had the following critical Geofencing scenarios which required attention while testing:

The Mobile application should show the end users Free Coupons for buying Coffee if the current location is in Spain.
It should not show any Free Coupons to the user if the current location is not in Spain.
If the user’s current location is Germany, it should provide the user with a discount coupon (10–15% discount on the total price) to buy coffee.

As we all were working remotely, the ultimate problem we faced here was our QA team was neither in Spain nor Germany. We were all working remotely from India. Now, the question which came to everyone’s mind was, “How do we test these Geofencing features?”

These were critical scenarios directly related to business and, if not tested well, may result in bugs related to the non-functional or mistargeted notifications and marketing services.

This could lead to overall poor customer experiences, eventually bringing a decline in rating on the App and PlayStore and finally impacting the business.

The GPS geolocation testing feature provided by the cloud platform in real devices came to our rescue. We mocked the GPS geolocations and performed all the testing seamlessly.

Let’s move to the next section of this blog to perform the testing related to GPS geolocation and IP geolocation on the LambdaTest cloud platform.

LambdaTest is a digital experience testing platform that offers a real device cloud to run GPS and IP geolocation tests on 3000+ real browsers, devices, and operating systems. With the LambdaTest cloud testing platform, you can perform live interactive and automated cross browser testing on real mobile and desktop browsers running on real operating systems.

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorial around Selenium testing, Playwright, Appium, and more.

Run your Jest testing automation tests in massive parallel across multiple browser and OS combinations with LambdaTest, Read more .

Testing GPS Geolocation and IP Geolocation on Real Devices

There are two ways in which we can perform GPS geolocation and IP geolocation testing on Real mobile devices:

Manual Testing
Automated testing

Manual Testing

Testing manually is easy, but it requires more effort and is time-consuming. As the same tests need to be repeated as a part of regression tests, it becomes a tiresome task for the test engineer. Also, repeatedly mocking the location to create the actual scenario for performing location-based testing makes it tedious.

While performing manual testing, chances are human error might also lead to bugs being released to the production environment.

This is where automation testing helps.

Automated Testing

Mobile automation testing, on the other hand, is the perfect solution for today’s world. It saves time and cost. Boring, tedious, and repeated tests can be automated and run as regression tests. It provides faster feedback in the builds leading to quick release time to market.

Let’s now get into automated testing and write some tests for geolocation testing using Appium.

Demonstration: Emulating GPS and IP Geolocation using Appium

In this section, we will write automated tests for checking the GPS geolocation and IP geolocation.

Test Scenarios

Before we move towards writing automated tests, let’s first discuss the scenarios that will be considered for this demo.

We will set mock GPS geolocation and IP geolocation on the LambdaTest cloud platform using the following Real mobile devices:

Samsung Galaxy S20 Plus
Samsung Galaxy Note 20

Test Scenario 1

The GPS geolocation and IP geolocation values will be passed in automated tests using the Appium Desired Capabilities.

After the GPS geolocation and IP geolocation are set, we will retrieve the latitude and longitude values in the test and compare them with the values we set using the desired capabilities.

Test Scenario 2

In this scenario, we will set the IP geolocation as “United Kingdom” and verify the Country name is correctly displayed after opening the Chrome browser in the Real Device — Samsung Galaxy Note 20 and navigating to the iplocation.com website.

We will be expecting this website to show the Country as “United Kingdom”.

Let’s move further to set up the project and implement the test scenarios.

In this XCUITest tutorial, learn about XCUITest framework and its benefits for mobile automation testing. Take a look at how XCUITest works and see how to use it to test your mobile applications

Test Setup and Implementation

We first need to create a Maven Project and add the dependencies for Appium Java Client and TestNG.

It is the best practice to update the versions of the dependencies in a separate properties block. This helps in maintaining the versions easily in a single place.

Let’s move ahead toward writing the automated tests now.

As discussed in the test scenarios, we will be setting the GPS geolocation and IP geolocation using Appium’s Desired Capabilities. The easy way to do that is using the LambdaTest Capabilities Generator. The Country, as well as the Longitude and Latitude, can be set using the Capabilities generator screen.

LambdaTest’s Capabilities generator automatically generates the required code per the values selected in the UI for setting the capabilities using the W3C protocol. We just need to copy the code and paste it into the place where we will be setting the capabilities for the automated tests.

Setting the Language, Framework, Tool, and Real Device

Setting the Geolocation

To open the Geolocation settings menu, click on the Real User Conditions link to expand the menu and view the Geolocation setting fields.

Let’s set the IP geolocation to “United Kingdom” and GPS Geolocation to “United Kingdom” as well by setting the Latitude to “51.5072” and Longitude to “0.1276“.

Once we set the IP and the GPS geolocation, the capabilities generator automatically generates the required lines of code for setting the GPS and IP geolocation.

Using the same code we get from the capabilities generator, DesiredCapabilities can be set as follows:

private DesiredCapabilities setCapabilities () {

   DesiredCapabilities capabilities = new DesiredCapabilities ();
   HashMap<String, Object> ltOptions = new HashMap<String, Object> ();
   ltOptions.put ("w3c", true);
   ltOptions.put ("build", buildName);
   ltOptions.put ("name", testName);
   ltOptions.put (MobileCapabilityType.PLATFORM_NAME, platform);
   ltOptions.put (MobileCapabilityType.PLATFORM_VERSION, platformVersion);
   ltOptions.put (MobileCapabilityType.DEVICE_NAME, deviceName);
   ltOptions.put (MobileCapabilityType.APP, app);
   ltOptions.put(MobileCapabilityType.BROWSER_NAME, "Chrome");
   ltOptions.put(MobileCapabilityType.BROWSER_VERSION, "107");
   ltOptions.put ("geoLocation", "GB");
   HashMap<String, String> locationObj = new HashMap<> ();
   locationObj.put ("lat", "51.5072");
   locationObj.put ("long", "0.1276");
   ltOptions.put ("location", locationObj);
   ltOptions.put ("isRealMobile", true);;
   ltOptions.put ("visual", true);
   ltOptions.put ("console", true);
   ltOptions.put ("devicelog", true);
   capabilities.setCapability ("lt:options", ltOptions);
   return capabilities;
}

Code Walkthrough (Test Scenario 1)

Here is the test method; we will be asserting the latitude and longitude in this test.

@Test
public void getGeoLocationCoOrdinatesTest() {
   Location location = driverManager.getDriver().location();

   assertEquals(location.getLatitude(), 51.5072);
   assertEquals(location.getLongitude(), 0.1276);
}

Location class, originally belonging to Selenium WebDriver, helps us in getting the Longitude and Latitude for the current location.

Using this class’s getLatitude() and getLongitude() methods, we can get the Latitude and Longitude, respectively. These values can be used to assert the value that we had set in the capabilities.

Code Walkthrough (Test Scenario 2)

Before we move toward the test, let me show you the configuration part, which will help us run the test in the mobile browser.

The following desired capabilities related to Browser Name and Browser Version will help open the Chrome mobile browser version 107 in the real mobile device.

Mobile emulators online from LambdaTest allows you to seamlessly test your mobile applications, websites,and web apps on mobile browsers and mobile devices.

Here is the code for verifying the test scenario 2 as discussed earlier.

@Test
public void testGeoLocation() {
 driverManager.getDriver().get(“https://iplocation.com/");
 IPLocationPage ipLocationPage = new IPLocationPage(driverManager);
 assertEquals(ipLocationPage.getCountryText(), “United Kingdom”);
}

In this test, we navigate to the iplocation website in the mobile browser and check the value displayed for the Country field.

The IPLocationPage class is created to store all the page objects here.

public class IPLocationPage {

   private DriverManager driverManager;
   private WebDriverWait wait;

   public IPLocationPage(final DriverManager driverManager) {
       this.driverManager = driverManager;
       wait = new WebDriverWait(driverManager.getDriver(), Duration.ofSeconds(30));
   }

   public String getCountryText() {
       return wait.until(ExpectedConditions.visibilityOfElementLocated
               (By.cssSelector(".table > tbody > tr:nth-child(4) > td"))).getText();
   }
}

getCountryText() method returns the text for the country field which is finally used in the test to assert with the country name “United Kingdom”. Notice that the CSS Selector locator strategy is used here to locate the element for the country field. This is because we are locating the element on the browser in the mobile device. Hence all Selenium WebDriver related locator strategies should work here.

Let’s now run the test and demo the actual execution of the automation test scripts.

Test Execution

There are two ways to run the tests

Using TestNG
Using Maven

Using TestNG

To run the tests using TestNG, a testng.xml file is required to be created and by right-clicking on the file and selecting the option Run ‘…\testng.xml’ the tests can be executed.

testng.xml file used to execute the tests is given below. In the second test, the value for the app parameter is not given, as we need to run the tests on a mobile browser.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="Lambda tests Mobile automation test suite" parallel="tests" thread-count="2" >
   <test name="Geolocation Automation Tests" >
       <parameter name="buildName" value="Android Build"/>
       <parameter name="testName" value="Lat and Long Geolocation tests"/>
       <parameter name="platformName" value="ANDROID"/>
       <parameter name="app" value="lt://APP10160531401673546544779159"/>
       <parameter name="version" value="11"/>
       <parameter name="device" value="Galaxy S20 Plus"/>
       <classes>
           <class name="io.github.mfaisalkhatri.mobileautomation.tests.AndroidTests">
               <methods>
                   <include name="getGeoLocationCoOrdinatesTest"/>
               </methods>
           </class>
       </classes>
   </test> <!-- Test -->
   <test name="IP Geolocation Automation Tests">
       <parameter name="buildName" value="Android Build"/>
       <parameter name="testName" value="IP Geolocation tests"/>
       <parameter name="platformName" value="ANDROID"/>
       <parameter name="app" value=""/>
       <parameter name="version" value="11"/>
       <parameter name="device" value="Galaxy Note20"/>
       <classes>
           <class name="io.github.mfaisalkhatri.mobileautomation.tests.AndroidTests">
               <methods>
                   <include name="testGeoLocation"/>
               </methods>
           </class>
       </classes>
   </test> <!-- Test -->
</suite> <!-- Suite -->

Here is the screenshot of the test run locally using IntelliJ IDE:

Using Maven

To run the tests using Maven, run the following command on the terminal:

mvn clean test -DLT_USERNAME=< LambdaTest Username >

-DLT_ACCESS_KEY=< LambdaTest_Access_key >

Here is the screenshot of the test results after tests were run locally using terminal:

Demonstration: Testing GPS Geolocation and IP Geolocation manually on Cloud Grid

To perform testing using LambdaTest, we first need to Register/Sign up on the LambdaTest Platform. Once registration is successful, you can log in to your LambdaTest Account, which will land you on the Dashboard page.

New Selenium IDE supports cross browser testing and parallel tests for automation along with record and replay function. Here’s why you shouldn’t miss out on it.

GPS Geolocation for App Testing in Real Device

Using the LambdaTest Cloud platform’s Real Devices, we can mock the GPS geolocation and perform the mobile application testing as per our requirement.

The steps below will help start with GPS geolocation testing of the mobile application.

Starting an Android Real Device Session

On the left-hand panel, click on Real Device >> App Testing.

From the App Testing screen, we can upload the mobile application using the Upload button and select the Android or iOS device as required for testing from the list of multiple real devices for Android and iOS with different OS versions.

Let’s perform the testing on the Android Real Device using the Google Maps application, which comes pre-installed on the Android Device.

Let’s select Samsung Galaxy S22 5G with Android OS version 13 and click on the START button.

Here the Proverbial App by LambdaTest is chosen as we need to provide one default application to load for mobile app testing.

The following screen will be displayed once we click on the START button to launch the real device.

Once the device is ready with the default app, we should see the following screen loaded with the real device and the Proverbial App launched by default.

Let’s click on the Home button to load the Home Screen of the Real Device.

Once the Home Screen is loaded, we should be able to see the following screen.

Let’s now open the Google Maps application and check the current location displayed by default.

Manual GPS Geolocation Testing on Real Mobile Devices

It shows the current location as Dublin. Now, let’s change the Geolocation and set it to Dubai.

To change the Geolocation, click on the Geolocation button and click the Set Location button as displayed in the screenshot below:

It will open a new screen (check the screenshot below) to set the location. We can use the latitude and longitude of the location to mock or type the actual place name.

Here, we will type the location name as DUBAI and click Yes to confirm the location.

The following confirmation message will be displayed on the screen.

Let’s now check if the current location is updated as DUBAI by reopening Google Maps and re-checking the current location.

The Geolocation was updated correctly as DUBAI. We can perform all the testing of the scenarios as per the location set easily.

Note: The same steps can be followed for iOS Real Devices, and GPS Location can be updated.

IP Geolocation for App Testing in Real Device

Using LambdaTest Cloud platform’s Real Devices, we can mock the IP geolocation and perform the mobile application testing as required.

The steps below will help start with IP geolocation testing of the mobile application.

Starting an iOS Real Device Session

On the left-hand panel, click on Real Device >> App Testing.

For this demo, let’s use iPhone 14 Pro Max Real Device with iOS 16 Version. For a demo, let’s use the Proverbial App by LambdaTest (Other Apps can also be uploaded using the UPLOAD button, Or we can provide the app URL from which it can be uploaded directly).

Once the selection is made for the App and Real Device, Click the START button on the right-hand top of the screen.

Let’s click on the GeoLocation button in the App to check out the current IP Location.

It will open the GeLocation window and show the current IP Geolocation as Dublin.

Manual IP Geolocation Testing on Real Mobile Devices

Now, let’s change the IP Geolocation to some other country — Canada. We can do this by clicking on the Change Geolocation menu and selecting the required Country from the Country dropdown list.

Once the Country is selected, the message will be displayed on the top of the screen as Updating Location.

Let’s now open the app again and click on the Geolocation button to verify that the IP location has been changed to Canada correctly.

And we can see that the IP Geolocation has been changed to Canada now.

Note: The same steps can be followed for Android Real Devices, and IP GeoLocation can be changed.

Automated Functional Testing tests helps to ensure that your web app works as it was intented to. Learn more about functional tests, and how automating them can give you a faster release cycle!

Conclusion

GPS Geolocation and IP Geolocation are important factors in testing location-based mobile applications and websites. Multiple important technology terms include Geotargeting, Geotagging, Geofencing, Geoblocking, and Localization.

In this blog, we went through a detailed demo of performing geolocation testing on Real Devices using the LambdaTest Cloud Platform with Appium. We can also use the Real Mobile devices from the LambdaTest Cloud Platform and set mock locations to perform sanity testing manually on websites and mobile applications.

Happy Testing!

How To Automate ServiceNow With Selenium

Faisalkhatri123 — Mon, 13 Mar 2023 10:20:54 +0000

As businesses grow, there is a need to digitize the processes as manual work becomes tedious. For example, a company with 5000+ employees must digitize its IT department for different works like Asset management, IT Operations, queries related to software, managing the Software licenses, etc.

ServiceNow, a cloud platform, provides service, operations, and business management solutions that organizations use to manage their digital workflows and streamline their business processes.

When it comes to testing ServiceNow, Selenium is a popular choice among organizations. Selenium is a widely used open-source automation testing framework that can be used to test ServiceNow workflows and ensure a high-quality user experience.

In this blog, we will learn how to test ServiceNow using Selenium WebDriver to ensure the workflows and applications are working as expected, ultimately improving the overall efficiency and quality of the testing process.

So, let’s get started!

What is ServiceNow?

ServiceNow offers a platform for a fast‑changing world. It is a cloud-based platform that helps to manage your day-to-day operations and plays an important role in enhancing the digital experience for users. The platform provides a wide range of tools and capabilities that can help organizations to improve their digital workflows, automate and optimize processes, and enhance communication and collaboration. ServiceNow helps digitize and unify organizations to find smarter, faster, better ways to make work flow.

Here are some of the figures from the QA 2022 and FY 2022 regarding ServiceNow business:

Discover the top 45 essential Vercel test cases along with its importance, types and usage for better understanding.

Now Platforms

Now Platform helps digitize your entire business by optimizing the processes and creating values on a single unifying platform. Check out the different Now Platforms provided below:

Source

Tokyo Release

ServiceNow releases are scheduled two times per year. That latest Tokyo release was done in Q4 of 2022. ServiceNow’s next release, Utah, is planned for Q2 2023. Check out the features from Tokyo General Availability release highlights.

As per the report, ServiceNow Inc improved its market share to approximately 0.79 % due to strong revenue growth of 20.12% overall.

What is ATF (Automated Test Framework)?

ServiceNow testing is performed on supported ServiceNow applications to ensure that the product is free from bugs and all the desired functionalities are working as per the business requirements.

ServiceNow has an Automated Test Framework for testing the ServiceNow applications. Automated Test Framework is an out-of-the-box test framework developed by ServiceNow. It helps test the functionalities in ServiceNow, allowing you to create and run automated tests on your ServiceNow instances (Production & Non-Production).

This is done using the special ATF plugin that aids in accessing the application. It is intended to test the changes you make to your instance and not the ServiceNow functionality.

Using ATF, we can verify and validate application functionalities, test end-to-end scenarios, server-side scripting tests, configurations, customizations, and many more.

Shortcomings of ATF

While the ATF of ServiceNow provides many benefits to organizations to test their digital workflows and applications, there are some potential drawbacks to consider, including:

ATF tests ServiceNow workflows in local browsers, but advanced testing requires external automation testing tools. ATF is primarily designed for form testing and might not be suitable for testing other modules, such as testing notifications or service portals.
ATF also requires monitoring of the tests that are run.
ATF may require manual intervention to run the next tests in succession instead of running the tests automatically once the current test is completed. This is where open-source frameworks like Selenium can be extremely useful for extensively testing the front-end components.

How to test ServiceNow using Selenium WebDriver?

After discussing ATF and its drawback, let’s consider Selenium WebDriver for testing ServiceNow’s Demo Developer instance website, as Selenium has all the required features for website testing.

Application Under Test (ServiceNow Instance)

ServiceNow’s Demo Developer instance is used for executing the tests (Tokyo Release). You can create the instance by following the below steps:

Sign up on the ServiceNow website.
Once you fill out the form, select the required options displayed after signing up. You should receive an email with the instance link, username, and password.
You can log in and perform the testing using this link and its credentials.

ServiceNow’s Demo Developer Instance — Login Page

Incident Creation Page

Incident List Page

As per the ServiceNow documentation, the instance hibernates after 10 hours, and refreshing it is required by logging into your ServiceNow account.

Getting Started with ServiceNow testing

Following tools/language has been used in writing and running the tests:

Programming Language: Java
Web Automation Tool: Selenium WebDriver (Version 4.8.0)
Test Runner: TestNG
Build Tool: Maven
Cloud Platform to run the tests: LambdaTest

Learn 37 excellent Wix test cases for testing websites by reading this guide. Every significant test case will be covered in detail in this guide, along with how to set up your Wix website testing.

Test Scenarios

We will target the New Incident Creation page and the Incident List page for automation. However, before we move on to those screens, we need to login into the developer instance. Hence our first scenario will be to automate the Login Screen.

The developer instance link will be different for different users as it is assigned by ServiceNow. It is not a common demo website that can be used by all.

Test Scenario 1:

Automate the login page by entering the username and password and clicking the Log in button.

Test Scenario 2:

Navigate to the New Incident page, and verify the header on the page to validate that we are on the right page before we start creating a new incident. Enter valid values in the Caller Name, Channel, select Service and finally, click on the Submit button to create a new incident.

Once the new incident is created, it is displayed on the Incident List page.

Test Scenario 3:

The third scenario will be to navigate to the Incident List page and verify the values displayed on the first row, checking that whatever values were entered at the time of the creation of the new incident are displayed correctly here.

In case you are wondering how to write effective test cases for your test scenarios, you can refer to this tutorial on the ServiceNow test case template.

Implementation

As discussed earlier, this project has been created using Maven.

Project Structure and Packages

Discover the top 90+ essential Shopify test cases to ensure your store’s functionality, performance, and customer experience. Download our comprehensive template now.

TestNG is used as a test runner. Once the project is created, we need to add the dependency for Selenium WebDriver and TestNG in the pom.xml file.

Dependencies in pom.xml

Versions of the dependencies are set in a separate properties block. This is done for easy maintainability. So, if you need to update the versions, you can do it easily without searching throughout the pom.xml file.

Properties block in pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>

   <groupId>io.github.mfaisalkhatri</groupId>
   <artifactId>servicenow-selenium-testing</artifactId>
   <version>1.0-SNAPSHOT</version>
   <packaging>jar</packaging>

   <name>servicenow-selenium-testing</name>
   <url>http://maven.apache.org</url>

   <properties>
       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
       <selenium.java.version>4.8.0</selenium.java.version>
       <testng.version>7.7.1</testng.version>
       <lombok.version>1.18.24</lombok.version>
       <maven.compiler.version>3.10.1</maven.compiler.version>
       <surefire-version>3.0.0-M8</surefire-version>
       <java.release.version>15</java.release.version>
       <maven.source.encoding>UTF-8</maven.source.encoding>
       <suite-xml>testng.xml</suite-xml>
       <argLine>-Dfile.encoding=UTF-8 -Xdebug -Xnoagent</argLine>
   </properties>

   <dependencies>
       <!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
       <dependency>
           <groupId>org.seleniumhq.selenium</groupId>
           <artifactId>selenium-java</artifactId>
           <version>${selenium.java.version}</version>
       </dependency>
       <!-- https://mvnrepository.com/artifact/org.testng/testng -->
       <dependency>
           <groupId>org.testng</groupId>
           <artifactId>testng</artifactId>
           <version>${testng.version}</version>
           <scope>test</scope>
       </dependency>
       <!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
       <dependency>
           <groupId>org.projectlombok</groupId>
           <artifactId>lombok</artifactId>
           <version>${lombok.version}</version>
           <scope>provided</scope>
       </dependency>
   </dependencies>

   <build>
       <plugins>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-compiler-plugin</artifactId>
               <version>${maven.compiler.version}</version>
               <configuration>
                   <release>${java.release.version}</release>
                   <encoding>${maven.source.encoding}</encoding>
                   <forceJavacCompilerUse>true</forceJavacCompilerUse>
               </configuration>
           </plugin>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-surefire-plugin</artifactId>
               <version>${surefire-version}</version>
               <executions>
                   <execution>
                       <goals>
                           <goal>test</goal>
                       </goals>
                   </execution>
               </executions>
               <configuration>
                   <useSystemClassLoader>false</useSystemClassLoader>
                   <properties>
                       <property>
                           <name>usedefaultlisteners</name>
                           <value>false</value>
                       </property>
                   </properties>
                   <suiteXmlFiles>
                       <suiteXmlFile>${suite-xml}</suiteXmlFile>
                   </suiteXmlFiles>
                   <argLine>${argLine}</argLine>
               </configuration>
           </plugin>
       </plugins>
   </build>
</project>

The first step is to create a DriverManager class, which will be used to start the specific driver for the required browser.

// Detect dark theme var iframe = document.getElementById('tweet-1603288996011945985-114'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1603288996011945985&theme=dark" }

Configuration (DriverManager class)

public class DriverManager {


    private static final ThreadLocal<WebDriver> DRIVER        = new ThreadLocal<> ();
    private static final String                 GRID_URL      = "@hub.lambdatest.com/wd/hub";
    private static final String                 LT_ACCESS_KEY = System.getProperty ("LT_ACCESS_KEY");
    private static final String                 LT_USERNAME   = System.getProperty ("LT_USERNAME");


    public static void createDriver (final Browsers browser) {
        switch (browser) {
            case REMOTE_FIREFOX:
                setupFirefoxInCloud ();
                break;
            case REMOTE_CHROME:
            default:
                setupChromeInCloud ();
        }
        setupBrowserTimeouts ();
    }


    public static WebDriver getDriver () {
        return DriverManager.DRIVER.get ();
    }


    public static void quitDriver () {
        if (null != DRIVER.get ()) {
            getDriver ().quit ();
            DRIVER.remove ();
        }
    }


    private static void setDriver (final WebDriver driver) {
        DriverManager.DRIVER.set (driver);
    }


    private static void setupBrowserTimeouts () {
        getDriver ().manage ()
            .timeouts ()
            .implicitlyWait (Duration.ofSeconds (30));
        getDriver ().manage ()
            .timeouts ()
            .pageLoadTimeout (Duration.ofSeconds (30));
        getDriver ().manage ()
            .timeouts ()
            .scriptTimeout (Duration.ofSeconds (30));
    }


    private static void setupChromeInCloud () {
        final ChromeOptions browserOptions = new ChromeOptions ();
        browserOptions.setPlatformName ("Windows 10");
        browserOptions.setBrowserVersion ("108.0");
        browserOptions.setCapability ("LT:Options", ltOptions ());
        try {
            setDriver (
                new RemoteWebDriver (new URL (format ("https://{0}:{1}{2}", LT_USERNAME, LT_ACCESS_KEY, GRID_URL)),
                    browserOptions));
        } catch (final MalformedURLException e) {
            System.out.print ("Error setting up cloud browser in LambdaTest " + e);
        }


    }


    private static void setupFirefoxInCloud () {
        final FirefoxOptions browserOptions = new FirefoxOptions ();
        browserOptions.setPlatformName ("Windows 10");
        browserOptions.setBrowserVersion ("108.0");
        browserOptions.setCapability ("LT:Options", ltOptions ());
        try {
            setDriver (
                new RemoteWebDriver (new URL (format ("https://{0}:{1}{2}", LT_USERNAME, LT_ACCESS_KEY, GRID_URL)),
                    browserOptions));
        } catch (final MalformedURLException e) {
            System.out.println ("Error setting up firefox  browser in LambdaTest " + e);
        }
    }


    private static HashMap<String, Object> ltOptions () {
        final HashMap<String, Object> ltOptions = new HashMap<> ();
        ltOptions.put ("username", LT_USERNAME);
        ltOptions.put ("accessKey", LT_ACCESS_KEY);
        ltOptions.put ("resolution", "2560x1440");
        ltOptions.put ("selenium_version", "4.0.0");
        ltOptions.put ("build", "ServiceNow Build");
        ltOptions.put ("name", "ServiceNow Tests");
        ltOptions.put ("w3c", true);
        ltOptions.put ("plugin", "java-testNG");
        return ltOptions;
    }


}

Code Walkthrough

Static Variables in the DriverManager class

ThreadLocal class is used here for setting the drivers as it is thread-safe and works very well when tests are run in parallel. The main reason behind using ThreadLocal is that two threads run in isolated ways.ThreadLocal variables, even if two threads set different values on the same ThreadLocal object.

Next is the GRID_URL, which must be set for running tests on the LambdaTest platform. Similarly, LT_USERNAME and LT_ACCESS_KEY are required to authenticate and start new sessions on the LambdaTest platform. You can set these capabilities from the LambdaTest Capabilities Generator.

Cloud testing platforms like LambdaTest allow you to perform cross browser testing at scale over an online browser farm of 3000+ browsers and operating systems. It offers a cloud Selenium grid, using which you can automate testing ServiceNow workflows to ensure a high-quality user experience.

Testing a site generator test cases website is crucial as it ensures the generated code is error-free & adheres to industry standards, providing a seamless user experience.

Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorial around Selenium testing, Appium, Playwright automation testing, and more.

Coming back to the LambdaTest Capabilities Generator, it helps you to generate desired capabilities for your Selenium tests in a set of key-value pairs that define the desired behavior of the browser or device under tests, such as browser name, version, platform, screen resolution, and more.

The parameter Browsers used in the createDriver() method is an enum (An enum type is a special data type that enables a variable to be a set of predefined constants), which is used to declare the Browser names on which we are planning to run the tests.

Configuration (Browsers(enum)

@Getter
public enum Browsers {


    REMOTE_FIREFOX,
    /**
     * LambdaTest Chrome browser.
     */
    REMOTE_CHROME


}

Notice the @Getter annotation above enum is imported from Lombok dependency and has to set the Getters for the variables set inside the enum on runtime, helping us to save time and effort by not writing the code for Getter methods inside this class.

Setting the Chrome and Firefox drivers in Cloud

Next important methods to note are setupChromeInCloud() and setupFirefoxInCloud(). These methods help set up Chrome and Firefox browsers in the LamdaTest cloud platform and help run the tests.

setupChromeInCloud() method

setupFirefoxInCloud() method

These methods have one thing in common — ltOptions, which are required to set the Configurations related to LambdaTest platforms in W3C format since Selenium 4 is W3C compliant. As both methods for setting up browsers need these ltOptions, a common method ltOptions() is created to set the respective configs.

ltOptions() method

How to write automated tests for ServiceNow workflows?

First, we write the base tests where the common configuration, like starting and quitting the drivers will be set up, and this base test will be extended to the Test Class, where actual tests will be written.

BaseTest class

public class BaseTest {


    @Parameters ("browser")
    @BeforeClass (alwaysRun = true)
    public void setupTest (final String browser) {
        createDriver (Browsers.valueOf (browser.toUpperCase ()));
    }


    @AfterClass (alwaysRun = true)
    public void tearDown () {
        quitDriver ();
    }


}

@Parameters annotation in TestNG is used to set the browser parameter from testng.xml. So if we need to run the tests on different browsers, we don’t have to change the code every time. The browser name could be updated in the testng.xml and the test could be run accordingly.

CreateDriver() method from the DriverManager class is called here to set the Drivers as per the Browser value passed.

createDriver() method (DriverManager class)

setupBrowserTimeouts() method is called for setting the browser timeouts after the driver is set.

setupBrowserTimeouts() method

All our configurations are now set, and we are ready to write the tests. Let’s jump into the Scenarios that we discussed earlier and write tests.

Implementation

Here is the test that covers all three scenarios discussed in the test automation strategy.

ServiceNowTests class

public class ServiceNowTests extends BaseTest {


    private static final String CALLER_NAME       = "John Adams";
    private static final String CHANNEL           = "Phone";
    private static final String SHORT_DESCRIPTION = "New incident created from automated test!";


@BeforeClass
     public void setup () {
        getDriver ().navigate ()
            .to ("https://dev21190.service-now.com/");
    }


    @Test
    public void testNewIncident () {
        LoginPage loginPage = new LoginPage ();
        loginPage.performLogin ();
        NewIncidentPage newIncidentPage = new NewIncidentPage ();
        assertEquals (newIncidentPage.getPageTitle (), "New record");


        IncidentListPage incidentListPage = newIncidentPage.createNewIncident (CALLER_NAME, CHANNEL, SHORT_DESCRIPTION);

        assertNotNull (incidentListPage.getIncidentNumber ());
        assertTrue (incidentListPage.getOpenedValue ()
            .contains (incidentListPage.getCurrentDate ()));
        assertEquals (incidentListPage.getShortDescriptionValue (), SHORT_DESCRIPTION);
        assertEquals (incidentListPage.getCallerNameValue (), CALLER_NAME);
        assertEquals (incidentListPage.getStateValue (), "New");
        assertEquals (incidentListPage.getCategoryValue (), "Inquiry / Help");
    }


}

Page Object Model is followed while writing the tests, and since we have three different pages to test; namely, Login Page, Incident Page, and IncidentList Page. Hence, three Page Object classes are created.

Implementation (Test Scenario 1)

As discussed in the automation testing strategy, let’s implement the Login Scenario, where the valid user will log in in the instance.

LoginPage class

public class LoginPage {


    private String userName = System.getProperty ("website_username");
    private String password = System.getProperty ("website_password");


    private WebElement userNameField () {
        return getDriver ().findElement (By.id ("user_name"));
    }


    private WebElement passwordField () {
        return getDriver ().findElement (By.id ("user_password"));
    }


    private WebElement loginBtn () {
        return getDriver ().findElement (By.id ("sysverb_login"));
    }


    public NewIncidentPage performLogin () {
        userNameField ().sendKeys (userName);
        passwordField ().sendKeys (password);
        loginBtn ().click ();
        getDriver ().navigate ()
            .to ("https://dev21190.service-now.com/incident.do");
        return new NewIncidentPage ();
    }
}

Login Page has all the locators for the Login Screen, which has fields like User name, Password, and the Log in button.

Locating the User name field

Username field has the ID locator in the DOM, which can be used to locate the field.

Similarly, the Password Field and Login button can be located using the appropriate locator strategies (e.g., Name, id, linkText, etc.)

Locating the Password field

Locating the Log in button

performLogin() method helps to login into the website. Here, we are not passing the username and password values in the method parameter. Instead, we get it using the System.getProperty() method.

This is done to ensure that we don’t expose the Username and Password secret values while testing. The values in the fields are entered using sendKeys() in Selenium WebDriver.

performLogin() method

Once the login is successful, we will navigate to the new incident creation page using its respective URL and return a new instance of NewIncidentPage.

Implementation (Test Scenario 2)

In Scenario 2, we discussed creating a new Incident by checking the page header first and then moving ahead to create a new incident.

New Incident Creation Page

Test for creating a new Incident

NewIncidentPage class is created for locating the fields required to create a new incident. createNewIncident() method performs the action required to create a new Incident.

NewIncidentPage class

public class NewIncidentPage {


    private WebElement callerNameField () {
        return getDriver ().findElement (By.cssSelector (".input-group > input#sys_display\\.incident\\.caller_id"));
    }


    private WebElement serviceField () {
        return getDriver ().findElement (
            By.cssSelector (".input-group > input#sys_display\\.incident\\.business_service"));
    }


    private WebElement serviceFieldHelpBtn () {
        return getDriver ().findElement (By.cssSelector (".input-group-btn > #lookup\\.incident\\.business_service"));
    }


    public void clickServiceFieldHelpBtn () {
        serviceFieldHelpBtn ().click ();
    }


    private Select channelField () {
        return new Select (getDriver ().findElement (By.cssSelector (".form-group select#incident\\.contact_type")));
    }


    public void selectChannelByVisibleText (String channelName) {
        channelField ().selectByVisibleText (channelName);
    }


    private WebElement shortDescriptionField () {
        return getDriver ().findElement (By.cssSelector (".form-group > div input#incident\\.short_description"));
    }


    private WebElement submitBtn () {
        return getDriver ().findElement (By.id ("sysverb_insert_bottom"));
    }


    private WebElement selectServicesLink () {
        return getDriver ().findElement (By.cssSelector (
            "#cmdb_ci_service > #cmdb_ci_service_table > tbody > tr:nth-child(2) > td:nth-child(3) > a"));
    }


    public void selectServices () {
        WebDriverWait wait = new WebDriverWait (getDriver (), Duration.ofSeconds (30));
        final String originalWindow = getDriver ().getWindowHandle ();
        wait.until (ExpectedConditions.numberOfWindowsToBe (2));
        for (final String windowHandle : getDriver ().getWindowHandles ()) {
            if (!originalWindow.contentEquals (windowHandle)) {
                getDriver ().switchTo ()
                    .window (windowHandle);
                selectServicesLink ().click ();
                break;
            }
        }
        getDriver ().switchTo ()
            .window (originalWindow);
    }


    public String getPageTitle () {
        return getDriver ().findElement (By.cssSelector ("h1 > div > div.navbar-title-display-value"))
            .getText ();
    }


    public IncidentListPage createNewIncident (String callerName, String channelName, String shortDesc) {
        callerNameField ().sendKeys (callerName);
        selectChannelByVisibleText (channelName);
        clickServiceFieldHelpBtn ();
        selectServices ();
        shortDescriptionField ().sendKeys (shortDesc);
        submitBtn ().click ();
        getDriver ().navigate ()
            .to ("https://dev21190.service-now.com/incident_list.do");
        return new IncidentListPage ();
    }


}

Lets deep dive into the createNewIncident() method. This method accepts three parameters, namely, callerName, channelName, and shortDesc, which will help us to generate a new entry for the incident.

The Caller Name field is an input text field. Lets locate this field using Chrome DevTools.

Our tutorial on Website Builder Test Case Templates offers comprehensive guide for effective website testing. Start optimizing your website’s quality today.

If you look closely, the id to locate the field in the DOM is “sys_display.incident.caller_id“.

However, when it comes to locating the field, the value for id is given as “#sys_display\.incident\.caller_id” (Notice the “\” in between the names before the “.”)

“\” is used as an escape character here, as in CSS Selector, “.” is used for class names. However, since we need to pass on dots for full id value, we must pass the “\” as an escape character.

In Java, “ \ ” is used for escape characters to pass the actual “\” for the String value. Hence for the CSS Selector value “ \\ ” is passed.

The Channel field is a single select dropdown list. In the DOM, we can see that it has the < Select > tag, which makes it easier to locate the field and use Selenium’s Select class to select the desired option and handle drop-down in Selenium.

Code to select the value from the Channel field

First, the Channel field is located using the CSS Selector, and a new instance of the Select class is returned from the channelField() method. selectChannelByVisibleText() method accepts the channelName as a parameter and selects the desired channel as provided in the text.

This passing of the parameter allows the tester to pass any visible text available in the field rather than hard coding any available value in the dropdown list.

The next field we need to locate and automate is the Service field.

To enter the value in this field, there are two ways, either type in the valid service name in the field or open the Service Search window and select the required service.

We will use the second way, i.e., open the Search Service window and choose the service of it. The steps that we need to perform are to click on the Search icon.

Here is the code snippet from the NewIncidentPage class, which will locate the Service field Help button and click on it.

Next, move the focus to the Search Service window and click on the Service name to select it.

selectServices() method performs all the major actions here. It will switch to the new window and select the service (The Second Service name from the Services list in the window is selected).

Here, for switching between windows, we need window handles of all the windows opened. A window handle is a unique identifier that holds the address of all the windows. It is a pointer that returns a String value.

The getWindowHandles() method helps us store the window handles and switch to the next open window.

Once the Service name selection is done, the Search Service window gets closed, and the focus needs to be shifted to the New Incident window. The following code line will ensure that the focus is shifted back to the original window. To learn more about it, you can go through this blog on handling Windows in Selenium.

getDriver ().switchTo ().window (originalWindow);

Next, the Short Description field is located, and text is entered in it as it is a mandatory field. After that, the Submit button will be clicked and using the below statement, we will navigate to the IncidentList Page.

getDriver ().navigate ()
            .to ("https://dev21190.service-now.com/incident_list.do");
        return new IncidentListPage ();

Assertions are the core of the test. With TestNG assertions, we will ensure that whatever data we have entered in the system using the New Incident Page is displayed correctly on the Incident List Page.

The record entered from the New Incident Page is reflected as the first on the Incident List Page.

Implementation (Test Scenario 3)

The IncidentListPage class is created to locate all the elements on this page and return the text of the first row.

IncidentListPage class

public class IncidentListPage {


    public String getOpenedValue () {
        return getDriver ().findElement (By.cssSelector ("#incident_table >tbody > tr:nth-child(1) > td:nth-child(4)"))
            .getText ();
    }


    public String getShortDescriptionValue () {
        return getDriver ().findElement (By.cssSelector ("#incident_table >tbody > tr:nth-child(1) > td:nth-child(5)"))
            .getText ();
    }


    public String getCallerNameValue () {
        return getDriver ().findElement (By.cssSelector ("#incident_table >tbody > tr:nth-child(1) > td:nth-child(6)"))
            .getText ();
    }


    public String getStateValue () {
        return getDriver ().findElement (By.cssSelector ("#incident_table >tbody > tr:nth-child(1) > td:nth-child(8)"))
            .getText ();
    }


    public String getCategoryValue () {
        return getDriver ().findElement (By.cssSelector ("#incident_table >tbody > tr:nth-child(1) > td:nth-child(9)"))
            .getText ();
    }


    public String getIncidentNumber () {
        return getDriver ().findElement (By.cssSelector ("#incident_table >tbody > tr:nth-child(1) > td:nth-child(3)"))
            .getText ();
    }


    public String getCurrentDate () {
        DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern ("yyyy-MM-dd");
        LocalDateTime now = LocalDateTime.now (ZoneId.of ("America/Los_Angeles"));
        return dateTimeFormatter.format (now);
    }
}

If you observe the Incident List Page Screen, it can be seen that it is a table, and values are respectively presented in rows and columns.

Incident List Page Screen with locators

You will find that most of the locators are located using the CSS Selectors, and the CSS Selectors are almost the same; only the respective child is changed at the end.

For example, CSS Selector for Opened Column and Short Description column are #incident_table > tbody > tr:nth-child(1) > td:nth-child(4) for opened Column.

#incident_table > tbody > tr:nth-child(1) > td:nth-child(5) for Short Description Column

nth-child matches every element that is the nth child of its parent. And since the Incident List Page has a table, we can just update the child reference, locate the required column, and get its value.

Now, coming to assertions in the test, in the test, the respective column value will be compared with the expected value that we used while creating a new incident.

With the assertions, we have completed our tests and covered all the scenarios we discussed as a test automation strategy.

Let’s now run the tests and check the result.

Test Execution

There are two ways to run the tests for verifying functionalities on the ServiceNow dashboard:

From the IDE using TestNG.
From the CLI using Maven.

Using TestNG

TestNG is used as a test runner; hence testng.xml has been created. Tests can be run by right-clicking on the file and selecting the option Run ‘…\testng.xml’.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="Service Now Tests Suite with Selenium WebDriver" parallel="tests">
    <test name="Testing ServiceNow Demo website on Chrome browser - LambdaTest">
        <parameter name="browser" value="remote_chrome"/>
        <classes>
            <class name="io.github.mfaisalkhatri.tests.ServiceNowTests">
                <methods>
                    <include name="testNewIncident"/>
                </methods>
            </class>
        </classes>
    </test> <!-- Test -->
    <test name="Testing ServiceNow Demo website on Firefox Browser - LambdaTest ">
        <parameter name="browser" value="remote_firefox"/>
        <classes>
            <class name="io.github.mfaisalkhatri.tests.ServiceNowTests">
                <methods>
                    <include name="testNewIncident"/>
                </methods>
            </class>
        </classes>
    </test> <!-- Test -->
</suite> <!-- Suite -->

The following four values need to be supplied as per the Test Configurations otherwise the tests won’t run:

LambdaTest Username
LambdaTest Access Key
ServiceNow’s Demo Developer Website Username
ServiceNow’s Demo Developer WebSite Password

These values can be passed as “-Dwebsite_username=< servicenow_username > -Dwebsite_password=< servicenow_password > -DLT_USERNAME=< LambdaTest Username > -DLT_ACCESS_KEY=< LambdaTest Access Key >”

Screenshot of the test run locally using Intellij IDE

Parallel Execution of the Tests:

The tests we just ran using TestNG were executed in parallel. In sequential execution, we have to wait for the first test to finish, and then only the next test gets executed.

Parallel execution saves time in test execution as all the tests are run in parallel at the same time.

For performing parallel testing in TestNG, we need to mention parallel=”tests” in testng.xml. Here, all the test blocks updated in testng.xml will start executing in parallel.

We have already used the ThreadLocal class in our code. Hence our execution will be thread-safe, so we don’t have to worry about things like test sessions overlapping, etc.

Using Maven

To run the tests using maven, the following steps need to be run:

Open command Prompt/Terminal.
Navigate to the root folder of the project.
Type the command on the terminal:

Screenshot of the test results run using Maven

Once the tests are run successfully, we can check out the LambdaTest Dashboard and view all the video recordings, screenshots, device logs, and step-by-step granular details of the test run in the LambdaTest Analytics.

Check out the screenshots below, which will give you a fair idea of the dashboard for automated app tests.

LambdaTest Dashboard

The following screenshots show the details of the build and the tests that were run. Again, the test name, browser name, browser version, OS name, respective OS version, and screen resolution are all correctly visible for each test.

It also has the video of the test that was run, giving a better idea about how tests were run on the device.

LambdaTest Build Details — Chrome Browser

ServiceNow Developer’s Demo Instance Test execution on Chrome browser on LambdaTest platform:

LambdaTest Build Details — Firefox Browser

ServiceNow Developer’s Demo Instance Test execution on Firefox browser on LambdaTest platform:

Over 57 different e-commerce test cases websites and application test cases are covered to guarantee a flawless and secure purchasing experience for customers.

Conclusion

In this blog, we discussed what ServiceNow is. We looked into the Now Platform and Automated Test Framework(ATF) created by ServiceNow.

Selenium WebDriver, as an external tool, was used to demonstrate how automated testing of the ServiceNow application can be performed over the Chrome and Firefox browsers using a ServiceNow Cloud Testing Platform like LambdaTest. I hope you enjoyed reading this blog and learned something from it.

Happy Testing!

How To Automate ServiceNow With Appium

Faisalkhatri123 — Tue, 07 Mar 2023 14:13:17 +0000

As organizations and businesses grow, managing the Operations, HR, and IT activities becomes quite difficult. Let’s take an example of a company with a 5000+ workforce, where multiple vendors and contractors are assigned different roles. So, when it comes to managing contracts, licenses, and different ventures, it becomes a tedious task.

To resolve such complex situations of managing the different operation activities,

ServiceNow, a cloud platform, provides service, operations, and business management solutions that organizations use to manage their digital workflows and streamline their business processes.

So, if a contract needs to be extended for a contractor, the contractor can use the application built on top of ServiceNow to apply for an extension. Now, with businesses working remotely, mobile applications come quite handy, where the senior management team can provide approval on the go as soon as they see a notification in the mobile app.

Benefits of using ServiceNow on Mobile:

It can be rebranded as our app by adding your logo, color theme, splash Screen, etc.
Tailored experiences can be delivered for routine employee needs from a single app.
It simplifies development by creating a customized, elegant app for Android and iOS.
It can create an immediate impact by providing out-of-the-box workflows for common use cases with seamless connection to data.

However, before we move towards releasing the mobile application to the end-customers (ideally a business), it is necessary to test it to validate that all the functionalities are working as expected. In the context of digital experience, ensuring that a product or service is functional and performs seamlessly across different devices and screen sizes is essential. This is because customers today interact with digital platforms using various devices, such as desktops, laptops, tablets, and smartphones, and the screen size and specifications of these devices can vary widely.

When testing ServiceNow mobile applications, Appium is a popular choice among organizations. Appium is a widely used open-source mobile automation testing framework that can be used to test ServiceNow workflows for shipping a full-functional top-quality mobile application.

In this blog on ServiceNow with Appium, we will learn how to test ServiceNow using Appium to ensure the workflows and applications are working as expected, ultimately improving the overall efficiency and quality of the testing process.

What is ServiceNow?

ServiceNow provides a cloud-based platform designed to keep up with the rapid pace of change in today’s world. This platform enables you to manage your daily operations effectively and plays a vital role in improving the digital experience for all users. With various tools and capabilities at its disposal, the platform offered by ServiceNow enables organizations to streamline their digital workflows, automate and optimize processes, and improve communication and collaboration. By unifying and digitizing operations, ServiceNow empowers organizations to discover more efficient and effective ways of making work flow smoothly.

Here are some figures from the QA 2022 and FY 2022 regarding ServiceNow business:

Now Platforms

The Now Platform is designed to streamline your entire business by optimizing processes and creating value through a unified platform. Explore the various Now Platform options below:

Black Box testing? Don’t worry; we will be covering what is Black box testing, merits, demerits, types & techniques.

Tokyo Release

ServiceNow follows a biannual schedule for its releases, with the most recent Tokyo release being launched in Q4 of 2022. The upcoming Utah release is expected to be rolled out in Q2 of 2023. To explore the features introduced in the Tokyo General Availability release, please refer to the release highlights.

This report indicates that ServiceNow Inc’s market share increased to around 0.79% due to a robust overall revenue growth of 20.12%.

How to Automate ServiceNow with Appium?

Before we move towards ServiceNow testing, it’s good to discuss the Application Under Test (AUT), the tools used, and the automation test strategy to define the scenarios for testing.

Application Under Test (ServiceNow Demo Application)

In this ServiceNow with Appium tutorial, ServiceNow’s mobile application is used for testing. It is available online and can be downloaded from the Google Play Store.

On clicking the “T*RY WITH A DEMO ACCOUNT*” link, the application will ask for a persona to choose, We will be choosing the “Service Desk Agent” option and accordingly will test the application further. Check out the Test Scenarios section below to learn more about the scenarios used for testing.

Getting Started with ServiceNow Testing

In this blog section on ServiceNow with Appium, let’s see how to get started with ServiceNow Testing.

Following tools/language has been used in writing and running the tests:

Programming Language: Java
Mobile App Automation Tool: Appium (Appium Java Client version 8.3.0)
Test Runner: TestNG
Build Tool: Maven
Cloud Platform to run the tests: LambdaTest

Test Scenarios

We will target the New Incident Creation screen and My Incidents page for test automation. However, before we move on to those screens, we need to launch the demo instance of the application and choose the Service Agent persona.

Test Scenario 1:

We will automate the following steps in the current test:

Launch the application, click on the “TRY WITH A DEMO ACCOUNT” link.
Choose Service Desk Agent persona and launch the demo app.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>io.github.mfaisalkhatri</groupId>
  <artifactId>servicenow-appium-testing</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>servicenow-appium-testing</name>
  <url>http://maven.apache.org</url>

  <properties>
    <appium-java-client-version>8.3.0</appium-java-client-version>
    <testng-version>7.7.1</testng-version>
    <lombok-version>1.18.26</lombok-version>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.version>3.10.1</maven.compiler.version>
    <surefire-version>3.0.0-M8</surefire-version>
    <java.release.version>11</java.release.version>
    <maven.source.encoding>UTF-8</maven.source.encoding>
    <suite-xml>testng.xml</suite-xml>
    <argLine>-Dfile.encoding=UTF-8 -Xdebug -Xnoagent</argLine>
  </properties>

  <dependencies>
    <!-- https://mvnrepository.com/artifact/org.testng/testng -->
    <dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>${testng-version}</version>
      <scope>test</scope>
    </dependency>
    <!-- https://mvnrepository.com/artifact/io.appium/java-client -->
    <dependency>
      <groupId>io.appium</groupId>
      <artifactId>java-client</artifactId>
      <version>${appium-java-client-version}</version>
    </dependency>
    <!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
      <version>${lombok-version}</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>${maven.compiler.version}</version>
        <configuration>
          <release>${java.release.version}</release>
          <encoding>${maven.source.encoding}</encoding>
          <forceJavacCompilerUse>true</forceJavacCompilerUse>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>${surefire-version}</version>
        <executions>
          <execution>
            <goals>
              <goal>test</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <useSystemClassLoader>false</useSystemClassLoader>
          <properties>
            <property>
              <name>usedefaultlisteners</name>
              <value>false</value>
            </property>
          </properties>
          <suiteXmlFiles>
            <suiteXmlFile>${suite-xml}</suiteXmlFile>
          </suiteXmlFiles>
          <argLine>${argLine}</argLine>
        </configuration>
      </plugin>
    </plugins>
  </build>

</project>

ServiceNow mobile application supports the latest two versions of Apple iOS and the latest four versions of Google Android.

In this ServiceNow with Appium blog, we will run the tests on LambdaTest Appium Grid on the Real Android device –Samsung Galaxy S21 5G with Android 12 version as it is the latest Android device and version as of now.

The first step is to create an AndroidDriverManager class, which will be used to start the Android driver to run the tests on Android devices.

@Builder
public class AndroidDriverManager {
    private static final ThreadLocal<AndroidDriver> DRIVER = new ThreadLocal<> ();
    public               Platform                   platform;
    public               String                     platformVersion;
    private              String                     buildName;
    private              String                     testName;

    private static final String LT_USERNAME   = System.getProperty ("LT_USERNAME");
    private static final String LT_ACCESS_KEY = System.getProperty ("LT_ACCESS_KEY");
    private static final String GRID_URL      = "@mobile-hub.lambdatest.com/wd/hub";
    private              String deviceName;
    private              String app;
    public AndroidDriverManager createAndroidDriver () {
        try {
            DRIVER.set (
                new AndroidDriver (new URL (format ("https://{0}:{1}{2}", LT_USERNAME, LT_ACCESS_KEY, GRID_URL)),
                    capabilities ()));
            setupDriverTimeouts ();

        } catch (MalformedURLException e) {
            throw new Error ("Error setting up android Driver", e);
        }
        return this;
    }

    public AndroidDriver getDriver () {
        return DRIVER.get ();
    }

    public void quitDriver () {
        if (null != getDriver ())
            getDriver ().quit ();
        DRIVER.remove ();
    }

    private void setupDriverTimeouts () {
        getDriver ().manage ()
            .timeouts ()
            .implicitlyWait (Duration.ofSeconds (30));
    }

    private DesiredCapabilities capabilities () {
        DesiredCapabilities capabilities = new DesiredCapabilities ();
        capabilities.setCapability ("lt:options", ltOptions ());
        return capabilities;
    }

    private HashMap<String, Object> ltOptions () {
        final HashMap<String, Object> ltOptions = new HashMap<> ();
        ltOptions.put (MobileCapabilityType.PLATFORM_NAME, platform);
        ltOptions.put (MobileCapabilityType.PLATFORM_VERSION, platformVersion);
        ltOptions.put (MobileCapabilityType.DEVICE_NAME, deviceName);
        ltOptions.put (MobileCapabilityType.APP, app);
        ltOptions.put (AndroidMobileCapabilityType.AUTO_GRANT_PERMISSIONS, true);
        ltOptions.put ("username", LT_USERNAME);
        ltOptions.put ("accessKey", LT_ACCESS_KEY);
        ltOptions.put ("build", buildName);
        ltOptions.put ("name", testName);
        ltOptions.put ("w3c", true);
        ltOptions.put ("isRealMobile", true);
        ltOptions.put ("network", true);
        ltOptions.put ("visual", true);
        ltOptions.put ("console", true);
        ltOptions.put ("devicelog", true);
        return ltOptions;
    }
}

This smoke testing tutorial covers what smoke testing is, its importance, benefits, and how to perform it with real-time examples.

Code Walkthrough

Static Variables in the DriverManager class

The use of ThreadLocal class in this context enables the safe setting of drivers, especially when running tests in parallel. This is because ThreadLocal provides thread safety and effectively isolates two threads, even if they set different values on the same ThreadLocal object. The primary advantage of using ThreadLocal is ensuring threads run independently and in isolation.

The following capabilities are necessary for running tests on the LambdaTest platform: GRID_URL, which must be configured, and LT_USERNAME and LT_ACCESS_KEY, which are required for authentication and creating new sessions. These capabilities can be set using the LambdaTest Capabilities Generator.

LambdaTest, a cloud-based testing platform, enables you to conduct comprehensive testing on a real device cloud consisting of over 3000 different devices and operating systems. This platform provides a cloud Appium Grid, which can be utilized to automate the testing of ServiceNow workflows, ensuring that your users receive a top-notch digital experience.

Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorial around Selenium testing, Appium, Playwright automation testing, and more.

LambdaTest Capabilities Generator

LambdaTest Capabilities Generator helps you set the capabilities by selecting the required configurations from the UI. Accordingly, it generates code that can be copy pasted easily into the project to start the mobile automation test hassle-free.

Setting the Desired Capabilities

Apart from the static variables, other variables are declared like platform, platform version, devicename, app, etc. The device will be assigned to run the test based on these configurations.

The code mentioned above utilizes the @builder annotation from the Lombok library, which facilitates the runtime passing of variable values such as platform, platform name, device name, and app.

Check out the Base Test and the Test Execution section below, where the steps related to passing the values for these variables are discussed.

Setting up Android Driver to run tests on the cloud

The next important method to note is the createAndroidDriver(). This method sets up the Android driver in the LamdaTest, a ServiceNow cloud testing platform with the help of Desired Capabilities and runs the tests.

createAndroidDriver() method

The setupBrowserTimeouts() method is called for setting the timeouts after the driver is set. The Implicit wait is added, so while searching for a single element, the driver should poll the page until an element is found or the timeout expires. This wait applies to all the elements on the Screen.

Likewise, Explicit wait can also be added for finding a specific element where we ask the driver instance to wait for a certain condition invoked through ExpectedConditions.

All our configurations are now set. Let’s now jump on to writing the automated tests.

How to write automated tests for the ServiceNow Demo Mobile application?

First, let’s write the base tests where the common configuration will be set up, like starting and quitting the Android driver.

This base test will be extended to the Test Class, where actual tests are implemented.

public class BaseTest {
    protected AndroidDriverManager androidDriverManager;

    @Parameters ({ "buildName", "testName", "app", "platformName", "platformVersion", "deviceName" })
    @BeforeClass (alwaysRun = true)
    public void setupTest (String buildName, String testName, String app, Platform platform, String platformVersion,
        String deviceName) {

        androidDriverManager = AndroidDriverManager.builder ()
            .buildName (buildName)
            .testName (testName)
            .app (app)
            .platform (platform)
            .platformVersion (platformVersion)
            .deviceName (deviceName)
            .build ()
            .createAndroidDriver ();
    }

    @AfterClass (alwaysRun = true)
    public void tearDown () {
        androidDriverManager.quitDriver ();
    }
}

The @Parameters annotation in TestNG enables the configuration of multiple parameters through testng.xml, obviating the need to modify the code repeatedly. Consequently, tests can be executed on various devices, platforms, and specific platform versions without any code modification. The corresponding settings for platforms, platform versions, devices, apps, etc., can be updated in the testng.xml, and the tests can be executed accordingly.

Implementation of Test Scenarios

Here is the test that covers all three scenarios discussed in the test automation strategy in the earlier section of this blog on ServiceNow with Appium.

public class ServiceNowAppTests extends BaseTest {

    @BeforeClass
    public void launchApp () {
        LaunchPage launchPage = new LaunchPage (androidDriverManager);
        launchPage.launchDemoApp ();
    }

    @Test
    public void testIncident () {
        MainPage mainPage = new MainPage (androidDriverManager);
        mainPage.createNewIncident ("New incident created using appium automation");
        IncidentListPage incidentListPage = new IncidentListPage (androidDriverManager);

        incidentListPage.searchForIncident ("email");
        incidentListPage.openIncident ();

        assertEquals (incidentListPage.getSeverityText (), "2 - High");
        assertEquals (incidentListPage.getTitle (), "No email! I cant't send or receive anything");
        assertEquals (incidentListPage.getCallerName (), "Francis Soo");
        assertEquals (incidentListPage.getDescription (),
            "I am not able to send or receive any email for the last 24 hours");
    }
}

A comprehensive Exploratory Testing tutorial that covers what Exploratory Testing is, its importance, benefits, and how to perform it with real-time examples.

While writing tests, the Page Object Model is adhered to, which involves creating four separate Page Object classes for the four pages that require testing: Launch Page, Main Page, New Incident Page, and Incident List Page.

Implementation (Test Scenario 1)

As discussed in the automation testing strategy, let’s implement the first scenario where a demo instance of the application will be launched, and the Service Agent persona will be selected.

The LaunchPage class has all the locators for the Launch Screen, which has fields like the Demo link, Service Desk Agent option, and Launch Demo button.

public class LaunchPage {

    private final AndroidDriverManager androidDriverManager;
    private final WebDriverWait        wait;

    public LaunchPage (final AndroidDriverManager androidDriverManager) {
        this.androidDriverManager = androidDriverManager;
        wait = new WebDriverWait (androidDriverManager.getDriver (), Duration.ofSeconds (30));
    }

    private WebElement tryDemoLink () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.id ("com.servicenow.fulfiller:id/btn_demo_account"));
    }

    private void clickOnTryDemoLink () {
        tryDemoLink ().click ();
    }

    private WebElement serviceDeskOptionMenu () {
        return wait.until (ExpectedConditions.elementToBeClickable (By.id ("itsm")));
    }

    private void clickServiceDeskAgentOption () {
        switchToWebViewContext ();
        serviceDeskOptionMenu ().click ();
    }

    private WebElement launchDemoBtn () {
        return androidDriverManager.getDriver ()
            .findElement (By.id ("launchDemo"));
    }

    private void clickLaunchDemoBtn () {
        launchDemoBtn ().click ();
        switchToNativeAPP ();
    }

    private void switchToWebViewContext () {
        wait.until (d -> androidDriverManager.getDriver ()
            .getContextHandles ()
            .size () > 1);
        androidDriverManager.getDriver ()
            .context ("WEBVIEW_chrome");

    }

    private void switchToNativeAPP () {
        androidDriverManager.getDriver ()
            .context ("NATIVE_APP");
    }

    public void launchDemoApp () {
        clickOnTryDemoLink ();
        clickServiceDeskAgentOption ();
        clickLaunchDemoBtn ();

    }
}

To locate the elements, the Appium Inspector application is used, which helps us easily to locate all the elements.

After opening Appium Inspector with all the required desired capabilities, locate the “TRY WITH DEMO ACCOUNT” link. We must locate and interact with this first element to start the demo application.

Locating the “TRY WITH A DEMO ACCOUNT” link

Appium Inspector shows that the link can be located using the id locator.

Here is the code to locate the element.

Let’s now locate the Service Desk Agent persona option and continue further to launch the demo app.

Locating the Service Desk Agent Persona option

If you notice the Application screen, this page runs inside WebView using Chrome. We can verify the different contexts in which the application runs using the Commands tab in Appium Inspector.

Checking Context using Appium Inspector

Select the Context in the first and the second dropdown boxes and click the Get Context List button. It will show all the available contexts for the application.

In WebView, we can see that the context is “WEBVIEW_chrome,” which we will be using to switch context so the elements on this page can be located. The elements will not be located until the context is switched, and Appium will throw NoSuchElementException.

Which are the most wanted test automation tools that have climbed the top of the ladder so far? Let’s take a look.

The serviceDeskOptionMenu() method locates the element for the Service Desk Agent option.switchToWebViewContext() method helps in switching to WebView context.

To click on the Service Desk Agent option, first, we need to switch to WebView, locate the Service Desk Agent option, and click on it.

The clickServiceDeskAgentOption() method performs the mentioned steps.

Next, we will locate the Launch Demo button.

Locating the Launch Demo button

The Launch Demo button can be located using the id locator. The following code will help in locating the Launch Demo button and clicking on it.

Next, we must switch back to the Native App context to move the focus back to the application.

The launchDemoBtn() method returns the locator for Launch Demo button and clickLaunchDemoBtn() will click on the button and switch to NATIVE_APP context.

Here is the launchApp() method, which runs before the test and launches the app with a Service Desk Agent instance demo. This method has the TestNG’s @BeforeClass annotation. @BeforeClass annotated method runs before the first test method in the current class is invoked. Hence, this method will be invoked before any test is run and will help to start the application under test successfully, so all our tests run smoothly.

Implementation (Test Scenario 2)

In Scenario 2, we discussed creating a new Incident by clicking on the “+” button on the Main Page.

Here is the implementation code for the test:

 @Test
    public void testIncident () {

        MainPage mainPage = new MainPage (androidDriverManager);
        mainPage.createNewIncident ("New incident created using appium automation");
        IncidentListPage incidentListPage = new IncidentListPage (androidDriverManager);

        incidentListPage.searchForIncident ("email");
        incidentListPage.openIncident ();

        assertEquals (incidentListPage.getSeverityText (), "2 - High");
        assertEquals (incidentListPage.getTitle (), "No email! I cant't send or receive anything");
        assertEquals (incidentListPage.getCallerName (), "Francis Soo");
        assertEquals (incidentListPage.getDescription (),
            "I am not able to send or receive any email for the last 24 hours");
}

The following lines in the above method is used for creating a new incident:

The NewIncidentPage class has been created to locate all the elements required for creating a new incident.

public class NewIncidentPage {

    private final AndroidDriverManager androidDriverManager;
    private final WebDriverWait        wait;

    public NewIncidentPage (final AndroidDriverManager androidDriverManager) {
        this.androidDriverManager = androidDriverManager;
        this.wait = new WebDriverWait (androidDriverManager.getDriver (), Duration.ofSeconds (30));

    }

    private WebElement callerField () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.id ("com.servicenow.fulfiller:id/valueLayout"));
    }

    private void selectCallerName () {
        callerField ().click ();
        wait.until (ExpectedConditions.elementToBeClickable (AppiumBy.accessibilityId ("Abraham Lincoln")))
            .click ();

    }

    public void setCallerName () {
        selectCallerName ();
    }

    private WebElement shortDescriptionField () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.accessibilityId ("Short description"));
    }

    public void enterShortDescription (String shortDesc) {
        shortDescriptionField ().sendKeys (shortDesc);
    }

    private WebElement submitBtn () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.accessibilityId ("Submit"));
    }

    public void clickSubmitBtn () {
        submitBtn ().click ();
    }
}

This page is self-explanatory as it locates the web elements on the New Incident screen and performs actions on it. However, before we come to this screen, there is a Main screen where we select the Create New Incident option. The MainPage class helps to locate the “create a new incident” link and perform a click action on it.

public class MainPage {

    private final AndroidDriverManager androidDriverManager;

    public MainPage (final AndroidDriverManager androidDriverManager) {
        this.androidDriverManager = androidDriverManager;
    }

    private WebElement quickActionBtn () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.accessibilityId ("Quick Actions"));
    }

The createNewIncident() method is the main method, which takes care of all the steps required to create a new incident. It accepts a parameter called short description, a mandatory field for creating an incident. This parameter is kept so any text can be supplied from the tests for setting “short description” while creating a new incident.

Test your native, hybrid, and web apps across all legacy and latest mobile operating systems on the most powerful Android emulator online.

For creating a new incident following steps needs to be taken care of:

Click on the Quick Actions button — This is done using the clickQuickActionsBtn() method.

Locating Quick Actions Button

The Quick Actions button can be located using the accessibility id “Quick Actions.”

Accessibility ID is the most preferred locator strategy in Appium. For Android, it is the content-desc property of the element, while for iOS, it’s the accessibility-id property. It is also one of the fastest-performing locator strategies.

clickQuickActionsBtn() method

Click the Open an incident option. This is done using the clickOpenAnIncidentOption() method, which returns a new instance of the NewIncidentPage class.

Locating Open an incident link

The “Open an incident” link can be located using the accessibility id -”Open an incident”.

clickOpenAnIncidentOption() method

Select the Caller Name and Short Description to create a new incident — this is done using the selectCallerName() method and enterShortDescription() methods, respectively.

Locating Caller Field and Caller Name

Though the id locator for the callerField is not listed in the Selected Element part of the screen. However, in the DOM, we can see that there is an id corresponding to the field

Let’s make use of this id locator to locate the field.

Locating the Caller Name

Here, accessibility id “Abraham Lincoln” can be used to locate the caller name. Here is the code implementation to select caller name

Caller field() and selectCallerName() method

Locating Short Description field

Accessibility id — Short description can be used to locate this field.

enterShortDescription() method

As soon as we type the Short Description in the field, the Submit button gets displayed on the screen. On clicking it, we can successfully create a new incident.

Locating Submit button

Let’s use the Accessibility id — Submit to locate the button.

clickSubmitBtn() method

The clickSubmitBtn() method is created, which clicks on the Submit button to create a new incident.

Implementation (Test Scenario 3)

In this scenario, as discussed in the test strategy, we will navigate to the My All Incidents page, filter the incidents based on the short description, and verify the contents of the incident.

Here is the implementation code for the test:

testIncident() Test

The IncidentListPage class is created to locate elements on this page.

public class IncidentListPage {
    private final AndroidDriverManager androidDriverManager;
    private final WebDriverWait        wait;

    public IncidentListPage (final AndroidDriverManager androidDriverManager) {
        this.androidDriverManager = androidDriverManager;
        this.wait = new WebDriverWait (androidDriverManager.getDriver (), Duration.ofSeconds (30));
    }

    private WebElement seeAllLink () {
        return wait.until (
            ExpectedConditions.visibilityOfElementLocated (AppiumBy.accessibilityId ("My incidents See all")));

    }

    private WebElement filterBtn () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.accessibilityId ("Filter button off"));
    }

    private WebElement shortDesc () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.accessibilityId ("Short description"));
    }

    private WebElement applyBtn () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.id ("com.servicenow.fulfiller:id/btn_apply"));
    }

    public void searchForIncident (String searchDesc) {
        seeAllLink ().click ();
        filterBtn ().click ();
        shortDesc ().click ();
        shortDesc ().sendKeys (searchDesc);
        applyBtn ().click ();
    }

    public void openIncident () {
        androidDriverManager.getDriver ()
            .findElement (AppiumBy.accessibilityId ("2 - High"))
            .click ();
    }

    public String getSeverityText () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.accessibilityId ("2 - High"))
            .getText ();
    }

    public String getTitle () {
        return androidDriverManager.getDriver ()
            .findElement (AppiumBy.accessibilityId ("No email! I cant't send or receive anything"))
            .getText ();
    }

    public String getDescription () {
        return androidDriverManager.getDriver ()
            .findElements (AppiumBy.id ("com.servicenow.fulfiller:id/tv_value"))
            .get (0)
            .getText ();
    }

    public String getCallerName () {
        return androidDriverManager.getDriver ()
            .findElements (AppiumBy.id ("com.servicenow.fulfiller:id/tv_value"))
            .get (1)
            .getText ();
    }
}

The searchForIncident() method is created to search for an incident based on the text supplied in its method parameter. This method performs the steps to click on the “See All” link using the seeAll link() method, which returns the WebElement for the link.

Locating the seeAll link

Accessibility id — “My incident See All” is available to locate the “See All” link.

seeAllLink() method

Next, the Filter button is clicked using the filterBtn() method, which returns the WebElement for the filter button.

Locating the Filter button

Accessibility id — “Filter button off” can be used to locate the filter button.

filterBtn() method

Next, we locate the Short Description field to enter the respective value in it to create a new incident.

This field can be located using the Accessibility id- Short description.

Locating the short description field

Once the short description is entered, the Apply button is displayed, clicking on it, the incidents with mentioned short description will be fetched.

Locating the Apply button

shortDesc() and applyBtn() methods

Once the record is retrieved, we need to get the texts from the fields like Caller Name, Title, Description, Severity, etc. The following methods will help us in getting all the required texts

Here is the code from the tests, which will perform all the required assertions

IncidentList page assertions

With the assertions, we have completed our tests and covered all the scenarios we discussed as per test automation strategy.

Let’s now run the tests and check the result.

Test Execution

From the IDE using TestNG.
Using Maven.

Using TestNG

TestNG is used as a test runner; hence testng.xml has been created. Tests can be run by right-clicking on the file and selecting Run ‘…\testng.xml’. As discussed earlier, we are running the tests on Android platform Version 11 and 12 respectively with devices Samsung Galaxy Note 20 and Samsung Galaxy S21 5G. All these configurations are set using the testng.xml file.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="Lambda tests Mobile automation test suite" parallel="tests">
    <test name="ServiceNow app - Android Mobile Automation">
        <parameter name="buildName" value="Android Automation with ServiceNow app"/>
        <parameter name="testName" value="ServiceNow App Tests"/>
        <parameter name="app" value="lt://APP10160531401676375222905553"/>
        <parameter name="platformName" value="ANDROID"/>
        <parameter name="platformVersion" value="11"/>
        <parameter name="deviceName" value="Galaxy Note20"/>
        <classes>
            <class name="io.github.mfaisalkhatri.tests.ServiceNowAppTests">
                <methods>
                    <include name="testLaunchDemoApp"/>
                    <include name="testIncident"/>
                </methods>
            </class>
        </classes>
    </test> <!-- Test -->
    <test name="ServiceNow app - Android Mobile Automation">
        <parameter name="buildName" value="Android Automation with ServiceNow app"/>
        <parameter name="testName" value="ServiceNow App Tests"/>
        <parameter name="app" value="lt://APP10160531401676375222905553"/>
        <parameter name="platformName" value="ANDROID"/>
        <parameter name="platformVersion" value="12"/>
        <parameter name="deviceName" value="Galaxy S21 5G"/>
        <classes>
            <class name="io.github.mfaisalkhatri.tests.ServiceNowAppTests">
                <methods>
                    <include name="testLaunchDemoApp"/>
                    <include name="testIncident"/>
                </methods>
            </class>
        </classes>
    </test> <!-- Test -->
</suite> <!-- Suite -->

The following four values need to be supplied as per the Test Configurations otherwise the tests won’t run:

LambdaTest Username
LambdaTest Access Key

These values can be passed as “-DLT_USERNAME= -DLT_ACCESS_KEY=”

Screenshot of the test run locally using IntelliJ IDE

Parallel Execution of the Tests:

The recently performed tests with TestNG were executed concurrently, which means that all the tests were run simultaneously. In contrast, in sequential execution, we need to wait for one test to finish before the next one can begin. Parallel execution is a time-saving approach for test execution because all tests are performed concurrently.

For performing parallel testing in TestNG, we need to mention parallel=”tests” in testng.xml. Here, all the test blocks updated in testng.xml will be executed in parallel.

Since we’ve incorporated the ThreadLocal class into our code, our execution is now thread-safe. Consequently, there’s no need to be concerned about issues like overlapping test sessions.

Using Maven

To run the tests using Maven, the following steps need to be run:

From Command Line:

Open command Prompt/Terminal.
Navigate to the root folder of the project.
Type the command on the terminal:

mvn clean test -DLT_USERNAME=< LambdaTest Username > -DLT_ACCESS_KEY=< LambdaTest Access Key >

Screenshot of the test results run using Maven

Check out the screenshots below, which will give you a fair idea of the dashboard for automated app tests.

LambdaTest Dashboard

The details of the build and the tests that were conducted are visible in the following screenshots. Each test includes the test name, browser name, browser version, OS name, respective OS version, and screen resolution, all of which are correctly displayed.

It also has the video of the test that was run, giving a better idea about how tests were run on the device.

LambdaTest Build Details

Details with Appium logs

Test Execution on Samsung Note 20:

Test Execution on Samsung Galaxy S21 5G:

Conclusion

In this ServiceNow with Appium tutorial, we discussed ServiceNow and its related mobile application and how it is useful in the digitization process.

We automated the ServiceNow mobile application using Service Desk Agent’s persona using Appium by running the tests on the LambdaTest Cloud platform’s Real Android Device. If you liked this blog, don’t forget to share it with your network, who may also benefit from it and help them learn.

Selenium 4 WebDriver Hierarchy: A Detailed Explanation

Faisalkhatri123 — Mon, 06 Mar 2023 09:33:56 +0000

The inception of Selenium can be traced back to a web application that required frequent testing. This prompted Jason Huggins to create a program using JavaScript, which he named JavaScriptTestRunner and released in 2004.

However, he realized that the program was much more powerful and could be helpful to the community in testing; hence, he decided to open-source it and renamed it to Selenium Core.

Paul Hammant created Selenium Remote Control (Selenium RC) or Selenium 1, an upgraded version of Selenium Core. It fixed the issue where testers had to install Selenium Core and the web servers containing the web applications. Hence, they belong to the same domain as the Same-origin policy prohibits JavaScript from being used from a different domain name from which it was launched.

Patrick Lightbody developed Selenium Grid for running the tests in parallel to reduce the test execution time to minimal. Shinya Kasatani from Japan contributed to the creation of Selenium IDE in 2006, which helps to automate the browser using record and playback features.

Selenium WebDriver was created in 2006 by Simon Stewart. Selenium WebDriver is an open-source, cross-platform library designed to help automate browser testing. It is designed to provide a simple and consistent interface for interacting with web browsers and different elements on the web page to simulate user actions on the websites. Over the years, Selenium has undergone many changes and improvements and introduced new features per the latest software industry trend.

It is composed of three main components:

Language Bindings — Language bindings are a set of classes and methods that allow you to use a specific programming language with Selenium WebDriver for writing automated tests for the website. Currently, WebDriver supports multiple programming languages, including Java, C#, Python, Ruby, JavaScript, etc.
WebDriver API — The API is a set of classes and methods that allow you to interact with the browser through code. The API allows running the tests on different browsers like Chrome, Firefox, MS Edge, etc.
WebDriver Implementation — WebDriver is an interface to access web browsers programmatically. It manages the communication between the language bindings and the browser. It lets you automate and interact with the elements in the DOM.

However, Selenium 4 is now W3C Compliant with Selenium 4. You may no longer be required to add ‘tweaks’ in the test script to make it work across different browsers, as everything (i.e., browsers & WebDriver APIs) runs in the W3C standard protocol.

If you are using Selenium 3 and want to get your hands dirty with Selenium 4, please check our detailed guide on upgrading from Selenium 3 to Selenium 4.

The introduction of Selenium Manager in Selenium version 4.6.0 is a big relief for the automation test engineers as it is not required to provide the executable driver path, nor do we need to use third-party libraries like WebDriverManager to start the browsers. Selenium Manager takes care of these browser drivers. We just need to have the respective driver installed in our machine on which we need to run the tests.

With WebDriver becoming completely W3C standardized, you can use it across different frameworks without any compatibility issues.

Though many of us would have used Selenium WebDriver for automation testing, there is a lower probability of each of us knowing the internals of architecture. The integral question is, “Does knowing the internal workings of Selenium and to what extent?.”

In my experience with Selenium, Appium, and other automation testing frameworks, understanding the internals of any framework helps in making the best possible use of the interfaces, classes, and methods provided by the same. We have witnessed how far Selenium has changed from its inception in 2002!

In this blog on Selenium 4 WebDriver Hierarchy, we will delve into the Selenium 4 WebDriver framework, specifically focusing on the hierarchy of the Selenium WebDriver and the abstract methods and nested interfaces within the WebDriver Interface. Additionally, we will also explore the hierarchy of the WebElement Interface and the abstract methods used within it.

Test your Puppeteer test scripts online. Deploy a quality build faster by running automated checks across over 3000+ browsers and OS combinations with the LambdaTest cloud. Try for free.

Selenium WebDriver Hierarchy

As an automation test engineer, we have been using Selenium WebDriver. Currently, while writing this blog on Selenium 4 WebDriver Hierarchy, Selenium’s latest version is 4.7.0. We know that by running the following line of code, the Chrome browser will be started, and we will be able to test the web page further using WebDriver methods.

WebDriver driver = new ChromeDriver();

However, very few automation test engineers know about the internal working of the WebDriver Interface. So, let’s dive deep into this and understand how Selenium WebDriver works.

Here is the pictorial representation of the Selenium WebDriver hierarchy.

RemoteWebDriver Class

Let’s start with the RemoteWebDriver class because it is a fully implemented WebDriver Interface class extended by every BrowserDriver class within the Selenium framework.

RemoteWebDriver class has the following nested classes:

RemoteTargetLocator — This is a fully implemented class of WebDriver.TargetLocator interface.
RemoteWebDriverOptions — This is a fully implemented class of WebDriver.Options interface. This class has the following nested classes:
RemoteTimeouts — This class implements WebDriver.Timeouts interface and provides the full implementation of all its abstract methods.
RemoteWindow — This class implements WebDriver.Window interface and provides the full implementation of all its abstract methods.

How to use the RemoteWebDriver class?

This class is important for running tests on cloud testing platforms like LambdaTest. As on the cloud platform, we may need to run the tests on multiple browsers and different platforms.

Cloud Selenium Grid like LambdaTest offers many benefits, including scalability, reliability, and security, which can be challenging to achieve with a local Selenium Grid. By performing Selenium automation testing on the cloud, it allows for a wider range of browser coverage, test coverage, and test execution in parallel, which is not possible in a local Selenium Grid.

Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around Selenium testing, Cypress testing, and more.

Since we are running on remote machines, we need to provide the remote URL, so the tests get executed correctly on the desired platforms and browsers.

RemoteWebDriver Class has the following constructors, which can be used to instantiate an instance of the class:

RemoteWebDriver(ICapabilities)

RemoteWebDriver(Uri, ICapabilities)

RemoteWebDriver(ICommandExecutor, ICapabilities)

RemoteWebDriver(Uri, ICapabilities, TimeSpan)

We will be using the RemoteWebDriver(Uri, ICapabilities) to run the tests on the LambdaTest platform. The capabilities shown in this example may differ from platform to platform as per their configuration settings. However, the usage of the RemoteWebDriver class remains the same.

Here is the screenshot of a method showing how we can use the RemoteWebDriver class to run the tests on the LambdaTest platform.

RemoteWebdriver class implements the following interfaces:

WebDriver
JavaScriptExecutor
TakesScreenshot
HasVirtualAuthenticator
PrintsPage
HasCapabilities
Interactive

Let’s talk about each of the interfaces implemented by RemoteWebDriver class in detail, starting with the WebDriver Interface first.

WebDriver Interface

WebDriver Interface is the core of the Selenium WebDriver as it has all the required methods and respective nested interfaces defined within it, which helps in simulating user actions inside the browser.

Following is the UML diagram of WebDriver Interface (Selenium WebDriver 4):

Get started with this complete Selenium guide of automation testing. Learn what Selenium is, its architecture, advantages and more for automated cross browser testing. Read more.

WebDriver Interface has the following abstract methods defined in it, which has no body, and these methods are fully implemented by RemoteWebDriver class

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

How to use the WebDriver Interface?

The WebDriver interface defines methods for interacting with a web page through a web browser. To use the WebDriver interface, you must first import the appropriate libraries and instantiate a WebDriver object.

Next, let’s move toward the nested interfaces within the WebDriver Interface and discuss them in detail.

Nested Interfaces within WebDriver Interface

The following are the nested interfaces within the WebDriver Interface. Let’s discuss each nested interface in detail.

Window Interface

This interface has all the methods that help manage the current window. Currently, at the time of writing this blog on Selenium 4 WebDriver Hierarchy, Selenium’s latest version is 4.7.0, and in this current version, this Window interface is in Beta.

This interface has the following abstract methods, which are fully implemented by the RemoteWebDriver Class:

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

How to use the Window Interface with WebDriver?

We need to instantiate the WebDriver interface by creating a new object by calling its implementing class. Once the object is created, we can simply use the Window interface as shown in the screenshot below:

Options Interface

This interface has all the methods to help manage the stuff in a browser menu. With the help of this interface, we perform the following actions:

Add, get, and delete a cookie
Set timeouts in the browser
Manage window
Fetch different types of logs. (This is in beta as per the latest Selenium WebDriver version 4.7.0)

Online Selenium Grid to run your browser automation testing scripts on cloud infrastructure containing 3000+ desktop and mobile browser environments. Perform Selenium Testing on a cloud automation testing grid that scales along with your tests.

This interface has the following abstract methods, fully implemented by the RemoteWebDriver Class.

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

How to use Options Interface with WebDriver?

We need to instantiate the WebDriver interface by creating a new object by calling its implementing class. Once the object is created, we can simply use the Options interface, as shown in the screenshot below.

Navigation Interface

This interface has all the methods to access the browser’s history and navigate to a URL. With the help of this interface, we perform the following actions:

Navigate Back, Forward in the browser
Navigate to a URL in the browser
Refresh the WebPage

This interface has the following abstract methods, which are fully implemented by the RemoteWebDriver Class:

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

How to use Navigations Interface with WebDriver?

We need to instantiate the WebDriver interface by creating a new object by calling its implementing class. Once the object is created we can simply use the Window interface as shown in the screenshot below:

TargetLocator Interface

This interface has all the methods to send future commands to different frames and windows. With the help of this interface, we perform the following actions:

Working with different Frames.
Working with different windows or Tabs in the browser.
Working with different Alerts in the browser.

This interface has the following abstract methods, fully implemented by the RemoteTargetLocator class, which is a nested class in the RemoteWebDriver class:

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

How to use TargetLocator Interface with WebDriver?

We need to instantiate the WebDriver interface by creating a new object by calling its implementing class. Once the object is created, we can simply use the TargetLocator interface, as shown in the screenshot below.

Timeouts Interface

This interface has all the methods to manage the timeout behavior for WebDriver instances. With the help of this interface, we perform the following wait actions in Selenium:

Implicit Wait
Script timeout
Page load timeout

This interface has the following abstract methods, which are fully implemented by the RemoteTimeouts class, which is a nested class in the RemoteWebDriver class:

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

How to use Timeouts Interface with WebDriver?

We need to instantiate the WebDriver interface by creating a new object by calling its implementing class. Once the object is created, we can simply use the Timeouts interface as shown in the screenshot below:

The following methods are deprecated as per the current Selenium Version 4.7.0:

implicitlyWait(long time, TimeUnit unit)
setScriptTimeout(long time, TimeUnit unit)
pageLoadTimeout(long time, TimeUnit unit)
setScriptTimeout()

Let’s now move towards the next interface that is implemented by RemoteWebDriver class.

JavaScriptExecutor Interface

JavaScriptExecutor Interface provides the mechanism to WebDriver so that it can execute JavaScript code snippets. This interface has the following two abstract methods, which are fully implemented in the RemoteWebDriver class.

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

TakesScreenshot Interface

This interface helps the WebDriver take screenshots of the web page or WebElement as required and store them in different ways. The screenshot captured is returned to the WebDriver endpoint in Base64 format.

This interface has the following abstract method, which is implemented in the RemoteWebDriver class:

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

HasVirtualAuthenticator Interface

This interface helps in allowing the WebDriver to access the virtual authenticator API.

A user’s public-key credentials can be stored in a hardware device, or a software entity called an authenticator. Authenticators help enable the key-based authentication mechanism in a passwordless manner. Virtual Authenticator emulates such authenticators for testing.This interface has the following abstract methods, which are fully implemented by the RemoteWebDriver class:

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

PrintsPage Interface

This interface allows the printing of the current page within the browser. It has the following abstract method, which is fully implemented in RemoteWebDriver class:

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

HasCapabilities Interface

This interface can be used for run-time detection of features by classes to indicate that they can describe their capabilities.

This interface is fully implemented by the RemoteWebDriver class and has the following abstract method:

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

With this, we come to the end of the discussion on the WebDriver interface. Let’s now jump on to another important topic around Selenium WebDriver, which is about WebElements and understanding its hierarchy.

WebElement Hierarchy

Knowing about WebElement hierarchy is also required. We can not run the web automation tests unless we locate the WebElements on the page to perform the required user simulation steps.

WebElement is an interface that extends the SearchContext and TakesScreenshot interfaces.

RemoteWebElement class is the fully implemented class of the WebElement interface.

The following image shows the WebElement in pictorial representation:

Which are the most wanted test automation tools that have climbed the top of the ladder so far? Let’s take a look.

Abstract methods declared within the WebElement Interface

As you can check in the UML diagram below, abstract methods are declared, which are implemented by the RemoteWebElement and EventFiringWebElement classes:

get(String url)	This method will return void and help us to navigate to the URL we provide in the method parameter.
getCurrentUrl()	This method will return the current URL of the web page.
getTitle()	This method will return the title of the current web page.
findElements(By by)	This method will return a list of webelements per the locator strategy called using Selenium’s By class which is an abstract class.
findElement(By by)	This method will return a webelement as per the locator strategy called using Selenium’s By class.
getPageSource()	This method will return the source of the last loaded page in the representation of DOM.
close()	This method will close the current window and quit the browser if it is the last window currently open.
quit()	This method quits the driver session, closing every associated window.
getWindowHandles()	This method will return a set of window handles that can be used to iterate over all open windows of this WebDriver instance.
getWindowHandle()	This method returns the current window handle, which is in focus within the current WebDriver instance. This can be used to switch to this window at a later stage.

With this, we come to the end of this blog on Selenium 4 WebDriver Hierarchy explaining the Selenium WebDriver’s architecture. Let’s summarize the points that we discussed.

Summary

With this blog on Selenium 4 WebDriver Hierarchy, I hope you are now fully aware and better understand the Selenium WebDriver architecture. I hope you will be able to utilize this knowledge in your project and make efficient use of the Selenium WebDriver framework. Some key takeaways:

RemoteWebDriver class is the fully implemented class of the WebDriver interface.
RemoteWebDriver class implements the following interfaces:
WebDriver
JavaScriptExecutor
HasCapabilities
HasVirtualAuthenticator
Interactive
PrintsPage
TakesScreenshot
Each BrowserDriver (ChromeDriver, FirefoxDriver, etc.) class extends the RemoteWebDriver class.
RemoteWebDriver class has the following nested classes:
RemoteTargetLocator
RemoteWebDriverOptions
RemoteTargetLocator class which is a nested class within RemoteWebDriver class that implements the WebDriver.TargetLocator interface.
RemoteWebDriverOptions which is a nested class of RemoteWebDriver class, implements the WebDriverOptions interface, and it has the following nested classes within it:
RemoteTimeout — This class implements the WebDriver.Timeouts interface.
RemoteWindow — This class implements the WebDriver.Window interface.
WebDriver interface extends SearchContext interface.
WebDriver interface has the following nested interfaces:
Options
Window
Timeouts
Navigation
TargetLocator
WebElement interface implements the SearchContext and TakeScreenshot interfaces.
RemoteWebElement and EventFiringWebElement classes are fully implemented classes of the WebElement interface.

Happy Testing!