|PREV NEXT||FRAMES NO FRAMES|
|Abbot GUI Automation|
|abbot||Provides testing support for Java GUIs.|
|abbot.finder||Provides component search and lookup facilities.|
|abbot.finder.matchers||Provides various types of Matcher implementations for use in component searches.|
|abbot.i18n||Provides internationalization support for Abbot and Costello.|
|abbot.tester||Provide component-specific actions and tests.|
|Abbot JUnit Extension|
|junit.extensions.abbot||Provide support for running scripts and UI-oriented unit tests as test cases under JUnit.|
|abbot.script||Provides basic elements for constructing a test script.|
|abbot.script.parsers||Provide explicit conversions from String to another class, for use by the interpreter when evaluating stringified values in scripts.|
|Costello Script Editor|
|abbot.editor||Provides support for editing Abbot test scripts.|
|abbot.editor.recorder||Provide recording support for component-specific user actions.|
|example||Miscellaneous examples demonstrating Abbot usage.|
This document is the API specification for the Abbot automated GUI testing framework and associated support packages.
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.
Top Abbot Home API w/FRAMES
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).
Robotclass are sufficient to reconstruct any user actions.
Component to be tested, there is a
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
JTableLocationmay be constructed with a
Point(raw coordinates), a [row, col] pair, or a
Stringrepresentation 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:
instead of many like this:public void actionClick(Component, ComponentLocation); public void actionDrag(Component, ComponentLocation); public void actionShowPopupMenu(Component, ComponentLocation);
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, thepublic 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
Stringvalue of a location will be used by default.
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.
provided for use with JUnit derives from
and is a very simple wrapper to adapt the script to the JUnit testing
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
ScriptTestSuite API documentation for details.
ComponentTestFixtureis provided for testing GUI components and groups of components directly from Java code. This fixture extends
TestCase, so you can manually write unit tests using any of the facilities of the framework.
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.
Click on 100, 100
Move to 110, 110
Press down key
Press down key
Click on 110, 110
Select "blue" from the color list
|PREV NEXT||FRAMES NO FRAMES|