|
||||||||||
PREV NEXT | FRAMES NO FRAMES |
See:
Description
Abbot framework | |
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.script | Provides basic elements for constructing a test script. |
abbot.tester | Provide component-specific actions and tests. |
abbot.util |
Abbot JUnit extension | |
junit.extensions.abbot | Provide support for running scripts as test cases under JUnit. |
Costello Script Editor | |
abbot.editor | Provides support for editing Abbot test scripts. |
abbot.editor.actions | |
abbot.editor.recorder | Provide recording support for component-specific user actions. |
abbot.editor.widgets |
Example Code | |
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. 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.
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 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.
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 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.
junit.framework.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.
The primary Recorder class is the EventRecorder, which calls out to specific instances of 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
|
||||||||||
PREV NEXT | FRAMES NO FRAMES |