A Java™ application can be configured in the testuite settings dialog. There are three different paths one can take to set the AUT.

Leave the Application as <No Application> and put the class name containing the main in the Main Class edit box.

Alternatively one can set a .jar in the Application field. This archive should have a proper MANIFEST included where the main class is listed. It is recommended however to not use this method, but add the .jar to the CLASSPATH and set the main class name as above. At least SWT based applications will not work with this setup.

And finally one can set a script or executable as AUT in the Application field. Please read section Java™ based applications (Section 16.3.5.2) carefully if you want to use a script, batch file or wrapper executable for your Java™ program. Testing RCP applications however, require only to set the launcher executable in this field.

Next section goes deeper in the subject of setting the AUT this way.

CLASSPATH can be configured in the Classpath edit box or outside of Squish as environment variable. Do not use any quotes, Squish get confused if paths are quoted.

	Note
	Use either a CLASSPATH environment variable set outside of Squish or use the Classpath edit box.

In Squish the application under test is not specified with its absolute path in the test suite. The reason for this is, that the test runner (squishrunner) doesn't directly execute the AUT, but that the squishserver will be instructed to start the AUT.

squishserver can be running on multiple machines where the AUT is located in different location. Therefore squishrunner only passes the name of the AUT's executable to squishserver and it is squishserver's responsibility to locate the executable and start it.

There are two different approaches to let squishserver know where an executable is located:

squishserver --config addAppPath <path>

squishserver --config removeAppPath <path>

squishserver --config addAUT myaut /home/squishuser/bin

squishserver --config removeAUT myaut /home/squishuser/bin

Another concept offered by Squish are settings groups. This way it is possible to save specific settings (such as an AUT path) under a settings group.

To explain the benefit of that we will look at a usage example which often occurs:

We want to create tests for an application called mycad. There exist two versions of the application, one in /usr/local/mycad_1_0/bin and the new version 1.1 is located in /usr/local/mycad_1_1/bin.

The tests we create should be ran against both versions. But without modifying the AUT paths or AUT mapping between each test run, it isn't possible to tell squishserver which version we want to launch.

In addition, only in version 1.1 we need to pass the argument --guifrontend to the application when starting it.

To solve this kind of problems, Squish introduces settings groups.

Setting up everything with settings groups is much easier in the Squish IDE so we discuss this way of doing it. First we create two settings groups: v1_0 and v1_1. To do this we open the test suite settings via Test Suite|Settings in the Squish IDE.

At the right top corner we can see a combobox which currently displays the default settings group and a button to add a new settings group:

By clicking this button, the two new settings groups can be added. Now all settings which will be specified (AUT, AUT path, arguments, etc.) will be added under the currently active settings group. To change the currently active settings group, select one in the combobox at the top right

When recording or replaying a test, it also is necessary to let the Squish IDE know which settings group to use. This way we can specify if e.g. version 1.0 or 1.1 of the AUT should be started. This can be done in the test suite settings dialog as well - just select the settings group to use in the combobox at the top.

squishrunner --settingsGroup <group> --testsuite <suite_directory> --record <test_case_name>

squishrunner --settingsGroup <group> --testsuite <suite_directory>

In some cases an application needs a special environment to be set up before it can start. This might include setting some environment variables, running a helper application and checking for some other conditions (enough memory available, etc.). Usually this is done by having a shell script or Windows batch file which does this pre-initialization work and then starts the actual application binary. See Shell Scripts and .bat-Files as AUT (Section 16.3.5) for details.

If only some environment variables need to be set up, the preferred way to do this when testing and application with Squish is to specify the environment variables in the test suite settings and use the application binary directly as AUT.

To specify environment variables, open the test suite settings in the Squish IDE via Test Suite|Settings and switch to the Environment Variables tab. In there it is possible to specify environment variables:

This way the specified environment variables will be set before squishserver starts the AUT.

In case the startup script of the application does more than just setting up some environment variables (see Setting Environment variables for the AUT (Section 16.3.4) for details), the best way is to specify the startup script as AUT instead of the actual application binary.

16.3.5.1. Non Java™ based applications

Note

Unix-Only: Even when specifying the script as AUT, you still need to add the actual AUT binary as known AUT to Squish. The reason for this is that Squish only hooks into white-listed programs started from an AUT. Since now the startup script is the AUT for Squish, the actual application binary, which Squish has too hook into, will be started by that script and not by Squish. Whitelisting is done by just adding the program as known AUT to Squish or by adding its path as AUT path. Adding an AUT or AUT path can be done on the command line or through the Squish IDE. See AUT Paths and Mapped AUTs (Section 16.3.2) for details.

On Unix and Mac OS X this works without any further adjustments. On Windows this requires a small change to the batch file which starts the application though: To allow Squish to hook into the application, the AUT needs to be started with a small wrapper application called dllpreload.exe.

So, instead of starting myapp.exe directly, you would e.g. put the following line into the batch file on Windows instead: c:\\squish\\bin\\dllpreload.exe myapp.exe.

This will start myapp.exe and allow Squish to hook into it. But you only want to do that when testing the application, otherwise the application should be started normally. This can be done by putting the following code into the batch file at the point where the application binary should be started:

IF "%1"=="-testing" (
	c:\squish\bin\dllpreload.exe myapp.exe
) ELSE (
	myapp.exe
)

Then you just need to specify -testing as an argument in the test suite settings so it will be passed to the AUT (the batch file in this case) by Squish on startup.

16.3.5.2. Java™ based applications

You can use shell scripts (or batch files) as AUT for starting Java™ applications. However for Squish to hook into the application, special arguments for the virtual machine must be set in the script that calls the java executable.

When starting the AUT, Squish sets two environment variables SQUISH_JAVA_DEF_1 and SQUISH_JAVA_DEF_2, which you can use to build the commandline. Also the CLASSPATH will be set by Squish.

	Note
	If you need your own classpath set, be sure to add the one Squish sets by appending $CLASSPATH or %CLASSPATH% to yours.

16.3.5.2.1. AWT/Swing

For AWT/Swing based Java™ applications the environment variable SQUISH_JAVA_DEF_1 contains the define (-Dsquish.wrapper=path) which sets the path to the AWT/Swing wrapper library. The SQUISH_JAVA_DEF_2 variable holds the -Xbootclasspath setting, which is necessary for the actual hooking.

16.3.5.2.2. SWT/RCP

Eclipse based Rich Platform Applications are supported by Squish. You should select the launcher program, by default called eclipse, as AUT.

For other SWT based Java™ applications, you should manually setup the java commandline. This is slightly different then with AWT/Swing scripts. Here the environment variable SQUISH_JAVA_DEF_1 sets the custom classloader (-Djava.system.class.loader=com.froglogic.squish.swt.SquishClassLoader). And the SQUISH_JAVA_DEF_2 variable holds the define (-Dsquish.libdir=path) that points to Squish library path.

For testing Java™ applets, a script (or batch file on Windows) has to be used. See Java™ based applications (Section 16.3.5.2) for the details about creating scripts or batch files. Squish uses the appletviewer from the Java™ SDK.

The appletviewer can pass arguments to the Java™ virtual machine with the “-J” option. So the scripts should look like

#!/bin/sh

$JAVA_HOME/bin/appletviewer -J$SQUISH_JAVA_DEF_1 -J$SQUISH_JAVA_DEF_2 PageWithApplet.html

And the content of a batch file should look like

%JAVA_HOME%\bin\appletviewer -J%SQUISH_JAVA_DEF_1% -J%SQUISH_JAVA_DEF_2% PageWithApplet.html

Note that the appletviewer expects the HTML page with the APPLET or OBJECT tag.

Finally, set the script (or batch file) as AUT in Squish.

Squish wraps a predefined set of Java™ classes. Only from wrapped classes scripts can access properties and methods on object instances. Likewise the spy can only show properties of wrapped classes. If a class isn't wrapped, only properties and methods from super classes can be used that are wrapped.

The squishserver can be used to extend the set of wrapped classes. The classes have to be listed in a .ini like the example below for java.lang.Integer and java.lang.Integer.

[general]
AutClasses="java/lang/Integer", "java/lang/Long"

The class names must be relative to the classpath. The command

squishserver --config setConfig <name-of-AUT> <path-of-ini-file>

will register the .ini. Note the name of the application in the above command is the exact name found in the Test Suite Settings dialog. Removing this registration is done by issuing this command with the removeConfig option, thus

squishserver --config removeConfig <name-of-AUT> <path-of-ini-file>

When an extra class is wrapped, all super classes, classes from method arguments and return type classes will be wrapped as well. If such a wrapping fails however, it will become an Unknown type.