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 approach.)

The application's source files are CanvasTest.java, MyCanvas.java, MyCanvasItem.java, MyCanvasGroup.java, MyCanvasShape.java, MyRectCanvasItem.java, MyCircleCanvasItem.java, 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 MyCanvas 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 MyCanvasItem objects, 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 MyCanvasFactory.java.)

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 variable 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 file).

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 squish/examples/java/suite_canvastest_js.