AOST- Abstract Object-based Selenium Test Framework

Jian Fang (John.Jian.Fang@gmail.com)

Outline

Overview of existing framework Motivations The New Selenium Test Framework AOST Details Resources

Overview of existing framework (1)

The existing framework is a bottom-up approach, which solves the problem that the selenium test is only good for user acceptance test at late stage of the development. The existing framework is UI-object based and you can start to develop the test when you start to create UI and also it does not reply on the record-and-replay strategy. Once you define UI objects, you can create the UI tests just like the regular Junit tests, you can create as many test cases as possible Multiple strategies are proposed to locate the locators of the UI compoents.

Overview of existing framework (2)

There are some drawbacks of the existing framework:

It uses factories to create UI objects and the procedure to define UI objects is pretty verbose The framework is written in Java and because of the limitation of Java, it lacks of dynamic features, which makes it painful to create tests Each UI objects in the framework talking directly to the selenium client and makes the code not very clear. For example, you can see a lot of getSelenium() calls in each object. Locate Strategies need to be improved a lot

Motivations

My vision of the selenium test framework:

Really useful Easy to use The framework should take care of as many work as possible so that users can focus more on test logics itself

With the advent of dynamic languages, I am really impressed by how easy to finish job using the frameworks based on dynamic languages. Groovy provides a lot of dynamic features and it can also integrate with Java smoothly, which make it possible for us to create DSL (Domain Specific Language) for selenium tests. New framework should be created to utilize the dynamic feature of Groovy so that it is really easy to write UI tests.

The New Selenium Test Framework (1)

Keep the abstract UI object concept from the existing framework Create a DSL for selenium tests so that it is expressive to define UI components and act on them, for example:
DefUI { InputBox(id: "google_inputbox", locator: "//input[@title='Google Search']") Button(id: "search_button", locator: "//input[@name='btnG' and @type='submit']") } type google_inputbox, CobraKai click "search_button"

The framework will take care of creating the actual UI objects and how to act on them.

The New Selenium Test Framework (2)

Exploit the features of each UI component, for example, a table will always come with a Table tag and may have other tags like td, th, and tr. Try to utilize all the features to help us locate a UI component automatically. Define composed UI objects such as widgets and try to consider the objects inside as a whole to find the locators. Not just consider the locator for one UI object separately. For example, the google search UI has one input box and two buttons. It may be possible to specify a common/base locator for them, and then based on the information that the search buttons follows right after the input box, we can automatically find the locators for the two buttons. Exploit the capability of the Selenium framework. Could we incorporate it with other Java script libraries such as Jquery to help us locate a UI component in the DOM?

The New Selenium Test Framework (3)

Based on the discussion above, we can create a Locator Query Languate (LQL) so that the users do L not need to locate the xpath/css selector for each UI component. Instead, the user can simply say select the UI component with one input box and two buttons identified by Google Search and Im Feeling lucky on the Google startup page. For the tests, the user just says: type inputbox Cobrakai and click on the Google Search button. In this way, the tests will become very expressive and pleasant. In the future, we may also like to create some help tools to convert the DOM or JSP files to UI Objects automatically.

The New Selenium Test Framework (4)

The framework provides Selenium Test case for users to extend to write their own tests in Groovy or Java. It will also provide DSL script engine and executor so that users who are not Java/Groovy developers can write DSL test scripts as .dsl files and run the tests by using the DSL executor. The framework should be flexible, reconfigurable, and extensible. For example, we may plugin in different test frameworks other than the selenium test framework in the future.

The New Selenium Test Framework (5)

The new selenium test framework is an abstract object-based Selenium Test framework, or AOST in short. Or a better name? The system architecture is shown in the next slide.

.dsl file DSL Script

Selenium Test Case Test cases UI Module

DSL Script Executor

AOST Selenium Test DSL Context

Tools

DSL Object Parser Builder Registry Object Builder Widget Object UI Object Container (group feature) UI Object (id, locator, features) Selenium Server

Event Handler

Data Accessor

Locator Processor LQL Engine

AOST Framework

Locator Query Language

Dispatcher Selenium Client Selenium Server JQuery

AOST - UI Object

UI Object includes

Id: should be unique in a UI module Namespace: for future extension Locator: the locator of the UI object, could be XPATH, CSS selector... The easier way to find the locator would be to use firefox XPather plugin. Features: the inherent feature of the UI component, for example, the selection UI component normally comes with label=? or value=?. Table always has the table, tr, td, th tags. The features can be used to help us to find the locators of the UI component. For example, once the base locator of a table is given, the i-th row j-th column should be handled automatically by the framework.

AOST Container and Widget

A container is a pure abstract object to hold and group different UI objects together. The container will make the objects inside searchable since it uses a list to hold them. The objects inside a container have location relationship, for example, UI Object A is right before B, which can be exploited by the Locator Query Language (LQL) It is possible that the whole container just holds a reference locator and all the objects inside it can simply derive their locators related to the reference locator We may need to cache the query result for the first time so that it can be reused. Widget will extend the container so that it has real meanings and can response to events.

AOST Object Builder

Object Builders are used to build the objects, which are usually used by the framework. Users are unlikely to use them directly. The builders utilize the ability to instantiate a groovy object by passing fields in a map. They also use the groovy Closure so that the framework can customize the building procedure. The builders are heavily used by the DSL object parser to create UI objects from DSL on the fly.

AOST Object Builder Registry

The object builder registry is designed so that the user can add new UI object to the DSL context at runtime. The object builder registry is a singleton class so that if the user like to add a new type of ui object to the DSL context, they can simply do:
New UiObjectBuilderRegistry().registerBuilder(new_name, new_builder)

The framework currently wired in all existing UI object builders in the constructor. Since the registry is a hash map, you can override a builder with a new one using the same UI name.

AOST DSL Object Parser

Thanks to Groovys builder pattern, we can define UI object expressively and in a nested fashion The DSL object parser will parse the DSL object definition recursively and use object builders to build the objects on the fly. The DSL object definition always comes first with a container. An object registry (A hash map) is used to stored all objects by their id. As a result, for each DSL object definition, the object ids must be unique in its scope. The object registry will be used by the framework to search objects by their ids and fetch objects for different actions.

AOST DSL Context

Domain Specific Language is a small language and can only lives inside its domain context. The DSL context is the heart of the our DSLs, i.e., all DSLs must live inside the DSL context. Thanks to Groovys syntax, all the methods defined in the DSL context can be written in a simple way, i.e., DSL expression. For example, the method
def click(String id){} defines the DSL: click id

DSL context includes three parts:

UI object definition UI event actions UI data access

AOST Event Handler

In the new framework, UI objects only hold data and will not interact with Selenium client directly. DSL Context will call the event handler to process the event like click. The event handler is the center place to react to an UI event. One UI event could be multiple steps in an actual action. For example, the action Type is composed of a serial of events like KeyUp, KeyDown, KeyPress, and KeyUp. Groovy metaClass is used to grant that the event handler is a singleton class. For each action, the event handler will first check if the object can really response to the action.

AOST Data Accessor

Data accessor is similar with the event handler and it is the center place to access the data from the UI. Such as getText() and check if a check box is really checked. More complicated data can also be obtained from the data accessor, for example, we can get the option list for a option selector. Data accessor is called by DSL context and it is also a singleton class.

AOST Locator Processor

DSL context calls the locator processor to get the actual locator of a UI object before doing some action on it. The objects locator data structure, which could be xpath, css selector, or description used by LQL, is passed to the locator processor. The locator processor will process the passed in data to get the actual object locator in form of xpath or css selector. The locator processor will call the LQL engine to process and get the actual object locator if necessary.

AOST LQL Engine

Locator Query Language will be a new and small query language to find the UI objects locator from the DOM object. LQL should be expressive and easier to use than xpath or css selector. Use Jquery to enhance the DOM query? Still thinking about it...

AOST - Dispatcher

The dispatcher will forward the events from the event handler and method calls from the data accessor to the selenium client. The dispatcher is designed for future extensible so that we can switch to different UI test servers like Selenium server.

AOST Selenium Client

The Selenium client is a place holder for the runtime selenium client we create after start up the selenium server. It is also a singleton class so that we can set the actual client to the singleton instance in run time. Thus, it removes all the redundant setSelenium() calls in the existing framework.

AOST Selenium Test Case

The selenium test case is imported from the existing framework, it includes a daemon thread to run the selenium so that we do not need to run the selenium server externally. Due to the limitation of GroovyTestCase, we cannot use annotation like BeforeClass and AfterClass, we have to use setUp() and tearDown() The registerMetaClass() method must be run before the tests, otherwise, you will not be able to get back the singleton instance for eventhandler, data accessor, and selenium client Users need to create UI modules (extends DSL context, like the example: GoogleStartPage) and then create as many tests cases as they want (extends AostSeleniumTestCase)

AOST Selenium Test Case (Contd)

User may like to customize the tests by setting baseUrl, useMultiWindows, and runSeleniumServerInternally User must put the firefox-bin in the environment path, or you can hard-code the path by change the following line to (not suggested): Need to take care of both http and https urls.

sel = new DefaultSelenium("localhost", port, "*firefox /usr/firefox-2.0.0.8/firefox-bin", baseURL);

AOST DSL Script Executor

The DSL script executor will be able to read DSLs from a .dsl file and run all the tests. Need to extend the DSL to include assert statements Under development...

AOST - Tools

Tools will help users to create UI tests. One type may be to help users to find the locators of UI objects Another type may be to convert the DOM or JSP files into DSL object definition so that the user can modify them to create UI tests More open for discussion

Resources

Groovy: http://groovy.codehaus.org/ JQuery: http://jquery.com/