UXD Legos AKA How To Design and Build the Page Object API of Your Dreams
Wouldn't it be great if building a page object was basically like putting together a bunch of legos? What if all you had to do is choose components from a API library of ready to use models of menus, paginators, chooser dialogs, data tables and so on? We could all stop reinventing the wheel over and over again. Every component of a given type would have the same basic interaction interface, resulting in a consistent look and feel for all your page objects. And, because the generic abstractions can be thoroughly unit tested and performance tuned, you can spend more time on testing your application in new and exciting ways rather than debugging routine interactions with that menu, that dialog, or that paginator.
Wouldn't it be even better if that page object API had an interface for dynamically specifying a configuration depending on the browser type, browser version and operating system so you wouldn't have to write a test setup script for each scenario? Your page object would know, for instance, to click that pesky button using a Javascript workaround for Firefox 31 on Windows 7 because WebElement.click() fails silently for just that combination of environmental factors. Your page object would also know that it needs twice as much time to load on Internet Explorer, and all you have to do is specify the configuration profile id for your test scenario. We've all spent more time trying to work around environmental snafus instead of finding bonafide application defects than we'd like.
What if you run into a variation on one of the generic models that is common enough that it should be another option in the API library? It would be great if the API had a cookie cutter approach to adding that new component, wouldn't it?
That cookie cutter process is as follows:
1) Identify the basic interface and interaction model for the component
2) Identify the minimal state that must be specified in order to construct the component
3) Identify the component's place in the inheritance hierarchy of other abstract components
4) Develop Java interfaces to define the contract for the component type, the contract for a state bean to specify the state necessary to construct it and the contract for a fluent builder to build and instantiate the component
Outline/Structure of the Case Study
- Introduce the most basic component, the 'Loadable' which consists of a WebDriver instance and a load timeout value, which is minimally sufficient to implement the SlowLoadableComponent design pattern in the Selenium support library
- Introduce the Java interfaces that define the contract for the Loadable component, its state bean, and its builder
- Introduce the abstract implementation for the Loadable and its builder
- Introduce the concrete default implementation of the builder and the state bean
- Introduce the next layer of component types: Expandable/Collapsible and Openable/Closeable components, their state beans and their builders
- Explore how the Decorator pattern implemented via interfaces with default method implementations allows components to have the behavior of multiple basic component types with very little additional code
- Explore more fully featured components, their state beans and builders:
- Menus
- Chooser dialogs
- Explore a sample page object composed of sub-components from the generic UXD component API
- Explore how to specify different configurations and see how the API models make use of your configuration settings
Learning Outcome
A development methodology for abstracting generic UI components that reduces boilerplate code and standardizes the interaction models of page objects built with components that inherit from same generic UXD implementations.
Target Audience
Framework Developers and Automation Engineers
Dave Haeffner Test
Anand Bagmar
Ru Vu
James Farrier
