AOST- Abstract Object-based Selenium Test Framework

butterbeanspipeΛογισμικό & κατασκευή λογ/κού

14 Ιουλ 2012 (πριν από 4 χρόνια και 11 μήνες)

354 εμφανίσεις

AOST- Abstract Object-based
Selenium Test Framework
Jian Fang

Overview of existing framework


The New Selenium Test Framework

AOST Details

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

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

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

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
anguate (LQL) so that the users do
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 “I’m 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
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
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
Selenium Server
Selenium Test Case
UI Module
DSL Context
UI Object
(id, locator, features)
Object Builder
Event Handler
Data Accessor
Selenium Client
AOST Framework
AOST Framework
Test cases
Selenium Server
UI Object Container
(group feature)
DSL Object
DSL Script Executor
DSL Script
.dsl file
AOST Selenium Test
Widget Object
Builder Registry
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

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:

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
New UiObjectBuilderRegistry().registerBuilder(new_name, new_builder)
AOST – DSL Object Parser

Thanks to Groovy’s 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 Groovy’s syntax, all the methods defined in
the DSL context can be written in a simple way, i.e.,
DSL expression. For example, the method

DSL context includes three parts:

UI object definition

UI event actions

UI data access

def click(String id){} defines the DSL: “click id”
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 object’s 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
AOST – LQL Engine

Locator Query Language will be a new and
small query language to find the UI object’s
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
AOST – Selenium Test Case (Cont’d)

User may like to customize the tests by setting
baseUrl, useMultiWindows, and

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-",
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

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