Abbot Automated GUI Testing Framework, v0.9.0
This document is the API specification for the Abbot automated GUI testing
framework and associated support packages, version 0.9.0
Abbot is a Java GUI testing framework. The framework may be invoked directly
from Java code (unit tests), or more simply using XML-based scripts. Both
methods are designed to be used with the JUnit testing framework. You can
launch a GUI, invoke arbitrary user actions on it, and examine its state. The
scripts may be invoked from JUnit or with minor modification any other testing
environment.
The Abbot framework also includes the Costello editor, which facilitates
editing scripts. The editor also supports recording arbitrary user actions
into a script.
The Abbot Framework
Abbot provides a framework for testing your GUI regardless of the current
state of your code. If you are doing test-first development with lots of unit
testing, then Abbot can provide the developer the tools needed to write
individual unit tests. If you have an existing code base without existing
unit tests, you can use the scripting level of Abbot to start building
functional test scaffolding around your application until it is sufficiently
stable to support refactoring and addition of unit tests.
In general, testing with Abbot consists of getting references to GUI
components and either performing user actions on those components or making
some assertions about their state. To facilitate this process, the framework
provides ComponentReferences to get a handle on a GUI component (even when it
may not yet exist), and Tester objects, which know how to perform user-level
actions on various GUI components.
Robot (the user event generator, and the root of all Testers)
This is the fundamental component of Abbot, "A Better 'Bot". It provides
basic component-level events upon which more complex tester objects can be
built. In the absence of a specific tester object for a given component, the
events provided by the Robot
class are sufficient to reconstruct any user actions.
Testers
provide component-specific user actions and tests (assertions). This is the
class to extend when you need to provide access to a custom GUI component.
The base class, abbot.tester.ComponentTester, provides default actions for
most common user actions, including clicking a mouse button, selecting from a
menu, and typing text. The tester system is easily extensible to provide more
specific actions or property lookup for custom components; for example,
JTableTester provides an action which selects the cell at a given row, column
location. JPopupMenuTester provides a method which returns a list of all the
menu items currently on a popup menu.
ComponentReferences
ComponentReferences allow you to use a few known attributes of a component to
refer to that component, whether or not the component currently exists or is
visible. When tests are run, component references are resolved just in time,
at the point where the component itself is actually needed. Component lookup
is fuzzy, such that irrelevant changes in attributes (such as position or size
of a component) generally won't affect the reference mapping.
Scripts
Scripts are the basic units of test execution in the Abbot framework. In
general these consist of component lookup
information,
component actions (such as menu selections, typed text, etc.), and assertions
regarding the GUI's state. Scripts for unit tests may be very simple, while
scripts for functional testing may be far more lengthy and complex. See the
abbot.script
package for more details.
When using a script, all information required to run the test is
encapsulated within the script itself, to provide independence from any
particular testing environment. This facilitates running the scripts under
either the script editor, JUnit, or some other harness.
The ScriptFixture
provided for use with JUnit derives from junit.framework.TestCase
and is a very simple wrapper to adapt the script to the JUnit testing
framework.
Scripts may be grouped into a test suite by using the
ScriptTestSuite
class, which can automatically collect a group of tests into a suite based
on file hierarchy, filenames, or other criteria. The preferred method of
creating a suite is to derive your test class from ScriptFixture, then have
the static "suite" method for that derived class create an instance of
ScriptTestSuite which selects for the scripts you wish to group. See the
API
documentation for details.
Editor (Costello)
A script
editor is provided to facilitate creation and maintenance of Abbot
scripts. The editor supports live recording of user events to facilitate
writing scripts, and can also play them back for debugging.
Recorders
Recorders
provide a means for the script editor to capture high-level semantic
information instead of basic mouse and key events. Recorders are provided for
most standard Swing components, but events will be captured properly even in
the absence of a customized Recorder for a given component. The editor
supports plug-in recorders to support additional custom components.
The primary Recorder class is the
EventRecorder,
which calls out to specific instances of
SemanticRecorder
to record component-specific actions.
Some Features of the Abbot Framework
Some of the features of Abbot that distinguish it from other testing harnesses
include the following:
- Scripted control of actions and inspection
Rather than writing new code which requires compilation, the test scripts are
dynamically interpreted, which is more appropriate for this level of tests.
All functionality, of course, is available for direct invocation in Java unit
test code.
- Loose component bindings
GUI layouts tend to change over time. A raw event recorder/playback
mechanism will likely break if you're operating in absolute coordinates;
different platforms generally size their components differently, so tests may
not work cross-platform. Abbot for the most part doesn't care where
components are positioned, as long as it can look them up dynamically with a
few tagging identifiers.
- Specify high-level semantic actions, but use low-level OS events to
implement them.
The java.awt.Robot class is capable of directly reproducing user events.
Unfortunately, it is far too basic to be easy to use for unit tests. Abbot
builds a level of abstraction on top of java.awt.Robot, mirroring the way
Swing Components are a level of abstraction above basic windows.
At this level, tests are much easier to maintain since you can deduce from a
glance what a set of instructions will do. It should be plain which of the
following groups of instructions it is easier for a human to parse:
Click on 100, 100
Move to 110, 110
Press down key
Press down key
Click on 110, 110
Select "blue" from the color list
- Support live recording of high-level semantic events.
While you can always write XML by hand, or edit each script step individually,
it makes more sense to leave it to the computer to do the grunt work. The
Costello editor can automatically record a sequence of user actions and save
them to a script.
- Extensible user action recording and generation
Tester and Recorder objects (as well as several other framework components)
are extensible to support any additional components you'd like to test,
although the basic Robot support can be used to test just about anything
without further modification. What you gain by adding extensions is a layer
of abstraction similar to calling ClickRow(10) instead of Click(x, y), where
(x,y) is the center of row 10.