Squish can work with all the standard AWT/SWT widgets out of the box. However, some custom widgets may represent their child components in a non-standard way, that is, not as AWT/SWT components. For example, a canvas might use normal Java objects to represent the items it displays. Or a Gantt diagram component might render its own contents, taking its data from a model. Squish's Java extension API makes it possible to extend Squish so that non-standard components in AWT and SWT applications can expose their APIs so that they become accessible to Squish and can therefore be accessed in test scripts like any other components.
In order to tell Squish what functionality to expose, we introduce the concept of an Inspectable class. An Inspectable class is one that can respond to Squish's queries about objects of a particular type. For example, an Inspectable could handle canvas item types, and provide an API that can give Squish the canvas's bounds or its parent, or that returns all of its child items. The precise APIs are listed in the Inspectable interface; see ???.
Once the Inspectables are registered, whenever Squish encounters an object, Squish queries each Inspectable to see if the Inspectable can handle the object (i.e., objects of the object's type). If one of the Inspectables reports that it recognizes the type as one it can handle, Squish uses that Inspectable's interface to interact with the object. This allows Squish to treat the object just like any of the standard AWT/SWT types that it supports out of the box—for example, Squish can query the Inspectable to see if the object has received a mouse click.
All the Inspectables for the types you want to Squish to be able to handle are placed together in a “wrapper” library. A clean way to do this is to put all the Inspectables classes in their own jar, although it is also possible to add them to the application's existing jar. The canvastest example shows how to put the Inspectables into their own jar.
Using the Java Extension API and a suitable wrapper, it is possible to support non-AWT/SWT components alongside standard AWT/SWT components so that Squish can:
To show how a wrapper to extend an existing AWT application works, we
will use the canvastest example which is
shipped together with the Java package. You can find the source code in
squish/examples/java/canvastest. (We could just as
easily have extended an SWT application using exactly the same
The application's source files are
and together they comprise
an AWT application that provides a simple canvas with multiple items.
We want test scripts that test the canvastest
application to be able to query the application's
objects—to retrieve a
MyCanvas, to get a
MyCanvas's parent object, to get the canvas's bounding
rectangle, and to get the
MyCanvasItem item at a particular
point, or all of the canvas's
MyCanvasItem items. In
addition, we want to be able to query
to get their bounding rectangles, and so on. To do all this we must
create suitable Inspectable Java classes that Squish can query to get
interfaces through which it can query the application's canvas and
canvas items as if they were standard AWT/SWT objects.
We have put the Inspectable classes in the
MyCanvasFactory.java file in the same directory as
the application's other Java files.
(At present we have no documentation for
Once the Inspectable classes have been created, Squish must be informed that they exist so that it can make use of them. All that is required to do this is to tell Squish which application the wrapper should be used for and where the wrapper is located. This is done by setting a configuration on the squishserver:
squishserver --config setConfig CanvasTest.jar \ $SQUISHDIR/examples/canvastest/Extension.ini
Here we have used a Unix-style path and assumed that the environment
SQUISHDIR has Squish's installation directory.
It doesn't matter what the path used actually is (so long as it is an
absolute path, and the correct one for the
Extension.ini must list the AUT's exposed
classes (i.e., those classes that the Inspectable classes handle on
Squish's behalf), and the directory where the extension is located.
Here's the canvastest's
Extension.ini file's contents:
[general] AutClasses="MyCanvasGroup", "MyRectCanvasItem", \ "MyCircleCanvasItem", "MyCanvas" JavaExtensionDir="."
To demonstrate testing the AUT with the wrapper we have provided a
very basic test suite in
The manifest file must contain an
Extension entry that has
as its value the class which has the
public static void
init(InspectableRegistry registry) method. This function is the
entry point for the extension and should register the factory class in
For applications that load their classes with one or more class loaders
that differ from the system class loader, an entry
LoadAtClass must be added. All RCP fall
in this category.
The value of this entry is the class that will trigger the extension registration, as soon as that class gets loaded by a class loader. This may require some trial and error, because all the fields of the factory classes that get registered must already be known to the class loader.