Enthused About: Widget Libraries for Browser Automation

At work, we use Selenium WebDriver (specifically, the Java API) for browser automation. Last December, we released our internal library which builds on WebDriver. We call it Extensions for WebDriver, or ExtWebDriver.

Since its first release, we've done a number of additional releases with relatively small enhancements. We've also presented the library to a number of test automation interest groups, the largest of which was the Metro NYC Selenium Users Group. That talk is immortalized on YouTube.

Today I thought I would write about what I consider to be the coolest feature of ExtWebDriver - its widget library approach.

The Selenium community generally promotes the use of an abstraction called the Page Objects, whereby the code for interacting with a single page of a web application is split into objects. In the ExtWebDriver library, we ship with out-of-the-box components defined at least one level deeper than Page Objects, which we call Widget Objects. An ExtWebDriver Widget Object (or Widget Class) knows how to interact with a single Widget. Automation engineers can leverage existing, well-tested, and often reusable widget objects when writing Page Objects or their equivalent.

The current version of the library (v. 1.4 as of this post) ships with a hierarchy of Widget Interfaces and concrete implementations for a basic Element and InteractiveElement. We also have a set of widget objects for standard HTML elements like Button, Input, List, Radio Group, and Table. In each object, you'll find the methods you'd probably expect. For example, Table ships with getRowNumber, getTableColumnCount, getTableDataInArray, getTableDataInMap, getTableHeaders, getTableRowColumnData (for a specific cell in the table), getTableRowCount, and isItemExist. Perhaps the most useful objects are the base objects below HTML like Element and InteractiveElement.

For those familiar with WebDriver, you may ask why we don't simply use the base WebElement class and extend it directly. For one thing, there's no promise that ExtWebDriver won't do this in the future (our latest release included use of the By locator objects from Selenium's framework). For now, the abstraction layer between ExtWebDriver's widgets and WebElement does isolate users of the library from the particulars of WebElement that may otherwise not be pertinent to a particular widget. The Element base class does provide a getWebElement method for direct access to the WebElement underlying any widget object instance.

As a designer, developer, and maintainer of browser automation solutions, I find the reusability of widget libraries attractive. The testability of UI front ends continues to be a driver for framework development as a whole (consider the "Testable" bullet on the AngularJS Homepage), and if we could aim to develop widget libraries for popular frameworks like GWT, jQuery UI, and Bootstrap, I think we could all (as the automation community at-large) more effectively minimize the tedious rework that many of us now carry out in isolation. I can envision frameworks in the future which deliver automation capabilities alongside every feature or UI widget of a framework. Automation-ability has become nearly synonymous with the ability to test effectively for fast-moving teams.

By the way, ExtWebDriver has plenty of other features, too! Another contribution of ExtWebDriver is its SessionManager, which includes a property-file based instantiation of thread-safe WebDriver sessions. You can get started with a quick example right here.