Java classes that are not Selenium page object classes, test classes, or data files, but support testing browser or mobile applications, can be considered utility classes. Most utility classes are static in nature, and use Java API methods that are not specific to any feature or test. They can include methods that operate on the browser or mobile device itself, but are not specific to the application running on them.

For example, the Selenium ExpectedConditions class has common methods to synchronize tests against actions occurring on a page, but it doesn't matter what the pages are, browser or mobile. Utilities can be built for file operations in reading, writing, or deleting files during tests. Test listener classes can be built, leveraging the TestNG TestListenerAdapter class, to log output to files and/or the console during test runs.

Other types of utilities...

Global variables are generally static in nature, can be initialized at the start of a test, and remain available throughout the entire test run. Variables for application defaults, timeouts, property file locations, paths, and so on can be stored in this class. To be clear, test data is not stored in this class. Test data will be encapsulated in a different file format, and will be discussed in later chapters. Here is an example of some default global variables:

/**
 * Global Variable Class
 * 
 * @author Author
 * 
 */
public class Global_VARS {
    // target app defaults
    public static final String BROWSER = "firefox";
    public static final String PLATFORM = "Windows 10";
    public static final String ENVIRONMENT = "local";
    public static String DEF_BROWSER = null;
    public static String DEF_PLATFORM = null;
    public static String...

One of the most important classes in the Selenium framework is the library containing all the test "synchronization" methods. In test automation, it is always necessary to "wait" for something to happen on a page after sending an event. That would include such actions as waiting for the page to render, waiting for an Ajax control to complete, waiting for a different page to appear, waiting for an item in a table, and so on. If test scripts are not synchronized, they will randomly fail when applications run faster or slower during execution, throwing exceptions that specific elements are not found. Selenium has introduced a set of classes that accommodate all of the types of synchronization that are required in browser and mobile testing.

The Selenium JavascriptExecutor class allows users to inject JavaScript commands directly into the context of the active browser frame or window. The use of this method is required in cases where the standard WebDriver class's methods fail to find or act upon an element on the browser page. JavaScript commands can be executed synchronously or asynchronously on the page. The class is an interface, and has been implemented for all the current driver classes. When designing a class to utilize this interface, users can pass commands directly to a WebElement by using the static locator, or one of the common locator methods available to WebDriver. Some of the more common methods will be outlined here:

In order to provide test results to the IDE console, or to a log file, users must build a test listener class into their framework. There are many open source classes available for use, as well as a TestNG class called TestListenerAdapter, which can be extended to provide custom logging information in real time. In other words, users can get results while the tests are running by logging them to the console, or by logging the data to a file.

How do you use it? How does it keep track of all the test results while the suite of tests are running? How does it get automatically called in a Selenium Framework Test Suite run? These questions will be answered in this section...

Another utility class that users will need to build is the file I/O class. This is a static Java class that contains all the methods for reading, writing, and deleting files, copying files, renaming files, accessing property files, finding files, setting file paths, extracting data, looking up messages, and many more. Storing all these similar methods in one central location for all CRUD operations (create, read, update, and delete) allows users to call these static methods from any page object or test class. Some of the more common methods will be outlined in this section.

Property files are common in testing, and are usually used for storing test environment data. There are various formats for...

Another important library to include in the framework is the image capture class. It is used by the test listener, reporter, and test classes to take screenshots of the browser or mobile screens when exceptions occur. There are various methods that can be built to capture the image of the entire screen, an individual WebElement or MobileElement, or to compare the images. Each method will be outlined here:

/**
 * Image Capture and Compare Class
 * 
 * @author Name
 * 
 */
public class ImageCapture {
    // constructor
    public ImageCapture() throws Exception {
    }

...