Abbot is a Java GUI testing framework and JUnit extension. The framework may be invoked directly from Java code (unit tests), or in a more simple, structured way 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 Abbot framework also includes the Costello editor, which facilitates editing scripts. The editor supports recording arbitrary user actions into a script.
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 extended Robot-like objects, which know how to perform user-level actions on various GUI components. These operations may be done from either a high-level script (useful for functional/acceptance testing) or directly from Java code (for example in a JUnit TestCase method).
For each {@link java.awt.Component} to be tested, there is a Tester class which provides user actions and tests (assertions) specific to that component. 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.
ComponentLocation
. This means that any component with
internal substructure (cells in a table, rows in a tree, items in a list, etc)
may identify a substructure location with a class derived from
ComponentLocation
. For example, a JTableLocation
may be constructed with a Point
(raw coordinates), a [row, col]
pair, or a String
representation of the value in the desired
cell. Using these location types avoids a proliferation of API methods, so you
can simply have one method per type of user action, like this:
public void actionClick(Component, ComponentLocation);
public void actionDrag(Component, ComponentLocation);
public void actionShowPopupMenu(Component, ComponentLocation);
instead of many like this:
public void actionClick(Component c, Point where);
public void actionClick[Cell](JTable c, int row, int col);
public void actionClick[Row](JTree c, int row);
public void actionClick[Value](JTable c, String value);
// Repeat for actionDrag, actionDrop, actionShowPopupMenuAt, etc
From a script, these are automatically generated as needed; in general you can
use (x,y), [index], [row,col], or "value" notations depending on how you want
to refer to a particular substructure element. When recording, the
String
value of a location will be used by default.
getOKButton
and
getCancelButton
. When tests are run, component references may be
converted to the actual Component they represent just in time, at the point
where the component itself is actually needed. Component lookup is fuzzy,
such that minor changes in attributes (such as position, parent or size of a
component) generally won't break the script.
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 {@link junit.extensions.abbot.ScriptFixture} provided for use with JUnit derives from {@link 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 {@link junit.extensions.abbot.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 {@link junit.extensions.abbot.ScriptTestSuite} API documentation for details.
This fixture takes care of providing a clean environment for instantiating, operating on, and examining GUI components, which includes properly disposing of all instantiated components at the end of each test. This avoids the tediousness of having to keep track of everything you displayed and tracking down anything that might have been displayed that you didn't know about (common when testing already-developed code). It also provides methods for looking up desired components in the hierarchy.
The primary Recorder class is the {@link abbot.editor.recorder.EventRecorder}, which calls out to specific instances of {@link abbot.editor.recorder.SemanticRecorder} to record component-specific actions.
Click on 100, 100
Move to 110, 110
Press down key
Press down key
Click on 110, 110
Select "blue" from the color list