Java Doc for ComponentTester.java in  » Testing » abbot-1.0.1 » abbot » tester » Java Source Code / Java DocumentationJava Source Code and Java Documentation

There are two sets of event-generating methods. The internal, protected methods inherited from abbot.tester.Robot 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 actionXXX 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). All public action methods should ensure that the actions they trigger are finished on return, or will be finished before any subsequent actions are requested.

Action methods generally represent user-driven actions such as menu selection, table selection, popup menus, etc. All actions should have the following signature:

public void actionSpinMeRoundLikeARecord(Component c, ...); public void actionPinchMe(Component c, ComponentLocation loc);

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.

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 ComponentTester.parseLocation(String) method, which should return a location specific to the component in question.

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 assertMyself(...);
public boolean assertBorderIsAtrociouslyUgly(Component c, ...);

Property checks may also be implemented in cases where the component "property" might not be readily available or easily comparable, e.g. see abbot.tester.JPopupMenuTester.getMenuLabels(Component) .

public Object getHairpiece(Component c);
public boolean isRighteouslyIndignant(Component c);

Extending ComponentTester

• Create the Tester Class

  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 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 javax.swing.JButton tester class is JButtonTester abbot.tester.JButtonTester , and a tester for org.me.PR0NViewer would be abbot.tester.extensions.PR0NViewerTester.

• Add Action Methods

  Add action methods which effect user actions. See the section on naming conventions below.

• Add Assertion Methods

  Add assert methods to access attributes not readily available as properties
  

• Add Substructure Support

  Add a corresponding ComponentLocation implementation to handle any substructure present in your Component. See ComponentLocation for details.

• Add Substructure-handling Methods

  • ComponentTester.parseLocation(String)
    Convert the given String into an instance of ComponentLocation specific to your Tester. Here is an example implementation from JListTester :
    

     public ComponentLocation parseLocation(String encoded) {
     return new JListLocation().parse(encoded);
     }
     

  • ComponentTester.getLocation(Component,Point)
    Use the given Point to create a ComponentLocation instance appropriate for the Component substructure available at that location. For example, on a javax.swing.JList , you would return a JListLocation based on the stringified value at that location, the row/index at that location, or the raw Point, in order of preference. If a stringified value is unavailable, fall back to an indexed position; if that is not possible (if, for instance, the location is outside the list contents), return a ComponentLocation based on the raw Point.

• Set Editor Properties

  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.PR0NViewerTester, 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)
  • PR0NViewerTester.actionWiggle.args javadoc-style description of method, displayed when asking the user for its arguments
  Since these properties are global, if your Tester class defines a method which is also defined by another Tester class, you must supply the class name as a prefix to the property.

Method Naming Conventions

When naming a selection method, include the logical substructure target of the selection in the name (e.g. JTableTester.actionSelectCell(ComponentJTableLocation) JTableTester.actionSelectCell()), since some components may have more than one type of selectable item within them.

This method is primarily used by the scripting system, since the appropriate ComponentTester for a given Component is not known a priori.

The abbot tester package is searched first, followed by the tester extensions package.

This method is primarily used by the scripting system, since the appropriate ComponentTester for a given Component is not known a priori.

This method is primarily used by the scripting system, since the appropriate ComponentTester for a given Component is not known a priori. Coded unit tests should generally just create an instance of the desired type of ComponentTester for local use.

The abbot tester package is searched first, followed by the tester extensions package.

This method is primarily used by the scripting system, since the appropriate ComponentTester for a given Component is not known a priori. Coded unit tests should generally just create an instance of the desired type of ComponentTester for local use.

The property abbot.robot.component_delay affects the default timeout.

The property abbot.robot.component_delay affects the default timeout. ComponentTester.waitForFrameShowing(Hierarchy,String)