Actions are generally user-driven actions such as menu selection, table selection, popup menus, etc. All actions should have the following signature:
public void actionWhat(Component c, ...);
It is essential that the argument is of type Component; if you use a more derived class then the actual invocation becomes ambiguous since method parsing doesn't attempt to determine which identically-named method is the most-derived. NOTE: All actions should ensure that the actions they trigger are finished or will be finished before subsequent operations before returning.
Assertions are either independent of any component (and should be implemented in this class), or take a component as the first argument, and perform some check on that component. All assertions should have one of the following signatures:
public boolean assertWhat(...);
public boolean assertWhat(Component c, ...);
Note that these assertions do not throw exceptions; normally these assertions will be wrapped by an abbot.script.Assert step if you want to cause a test failure, or you can manually throw the proper failure exception.
Property checks may also be implemented in cases where the component "property" might not be readily available or easily comparable, e.g. see JPopupMenuTester.getMenuLabels()
.
public Object getProperty(Component c);
public boolean isProperty(Component c);
Be careful not to name any support methods with the property signature, since these are scanned dynamically to populate the editor's action menus.
There are two sets of event-generating methods. The internal, protected methods inherited from abbot.tester.Robot are for normal programmatic use within derived Tester classes. No event queue synchronization should be performed except when modifying a component for which results are required for the action itself.
The public actionX functions are meant to be invoked from a script or directly from a hand-written test. These actions are distinguished by name, number of arguments, and by argument type. The actionX methods will be synchronized with the event dispatch thread when invoked, so you should only do synchronization with waitForIdle when you depend on the results of a particular event prior to sending the next one (e.g. scrolling a table cell into view before selecting it).
The ComponentLocation abstraction allows all derived tester classes to inherit click, popup menu, and drag variants without having to explicitly define new methods for component-specific substructures. The new class need only define the parseLocation(String)
method, which should return a location specific to the component in question.
Derive from this class to implement actions and assertions specific to a given component class. Testers for any classes found in the JRE (i.e. in the java.awt or javax.swing packages) should be in the abbot.tester
package. Extensions (testers for any Component subclasses not found in the JRE) must be in the abbot.tester.extensions
package and be named the name of the Component subclass followed by "Tester". For example, the javax.swing.JButton tester class is abbot.tester.JButtonTester
, and a tester for org.me.MyButton would be abbot.tester.extensions.MyButton
.
Add-on tester classes should set the following system properties so that the actions provided by their tester can be properly displayed in the script editor. For an action "actionWiggle" provided by class abbot.tester.extensions.ExtendedTester, the following properties should be defined:
actionWiggle.menu
short name for Insert menu actionWiggle.desc
short description (optional) actionWiggle.icon
icon for the action (optional) ExtendedTester.actionWiggle.args
javadoc-style description of method, displayed when asking the user for its arguments
|
|
|
|
|
|
|
|
|
|