This section discusses many aspects of applications under test, such as how they are located, how they can be specified, and various special settings that can be used with Squish.
A Java™ application can be configured in the Test Suite's Settings view (Section 16.2.14). There are four different ways that the AUT can be set—they are summarized below, with further details after the summary.
Leave the Application as
<No Application> and enter the name of the class
that has the application's static
main method in the
Main Class edit box—for example,
(This approach cannot be used for Java/SWT
applications unless the
CLASSPATH points to the
Set the Application to be the name of
.class file—providing that this file has
the application's static
(This approach cannot be used for Java/SWT
applications unless the
CLASSPATH points to the
Set the Application to be the name of
.jar archive—providing that
the archive contains a suitable
MANIFEST file that
lists the application class that has the application's static
(This approach cannot be used for Java/SWT
Set the Application to be the name of a script or other executable.
When testing RCP applications it is sufficient to set the Application to be the name of the launcher executable.
For Java/SWT applications one approach is to create a shell script or batch file to set as the Application.
On Unix-like systems create a one line shell script to use
as the AUT and that includes the
java -cp "$PWD":"$PWD/../swt/swt.jar" MyApplication
Similarly, on Windows, create a one line batch file. For example:
start javaw -cp "%CD%;%CD%\..\swt\swt.jar" MyApplication
In both examples we have assumed that the
An alternative to using a shell script or batch file is to set the
Note that the
CLASSPATH environment variable can be set
in the Test Suite's Settings view (Section 16.2.14)'s
Classpath edit box or outside
of Squish as an environment variable for the system in the usual way
for the platform you are using—only one of these need be used, not
both. (If you set the
CLASSPATH inside Squish, do not
In Squish, only the name of the application under test is stored in the test suite's configuration file, not its absolute path. This is because the test runner (squishrunner) doesn't execute the AUT itself, but instead it tells the squishserver to start the AUT. The squishserver can be running on multiple machines, and the AUT could be located on a different path on each of them. When squishrunner gives the squishserver the name of an AUT to run, it is the responsibility of the squishserver to locate the AUT and to start it running.
There are two different ways that we can tell the squishserver where an executable is located—both of them are explained below. (Note also that registering and unregistering AUT paths and AUTs can be done using the Squish IDE; see the Manage AUTs dialog (Section 16.3.4).)
The AUT Path is a variable in squishserver's settings which specifies
a list of paths (just like the operating system's own
PATH environment variable). When the
squishserver is given the name of an AUT to start, it searches all of
the paths in the AUT Path variable, and as soon as it finds a path that
contains an executable with the name it was given, it starts it running.
To add a path to the squishserver's AUT Path variable, execute:
squishserver --config addAppPath <path>
To remove a path from the AUT Path variable, execute:
squishserver --config removeAppPath <path>
The same can be done using the Squish IDE's Manage AUTs dialog (click | to invoke it). To add a path to the AUT Path, click on the AUT Paths item, then click the button and choose a path from the file dialog that pops up. Similarly, to remove an AUT Path, expand the AUT Paths item, click the unwanted path, then click the button.
Instead of having the squishserver look through all the AUT Path's paths for an AUT's executable, we can create mappings that directly relate AUT names to their corresponding paths. If we do this, when the squishserver is given the name of an AUT to execute, it starts by seeing if the name is mapped to a path—and if it is, squishserver starts the application directly using the mapped path. This avoids the (usually insignificant) overhead of searching all the AUT Path's paths.
An additional benefit of using the mapping approach is that it prevents the possibility of accidentally executing the wrong AUT. (Without using a mapping this could happen if two different executables have the same name and when trying to execute one of them the other is unintentionally executed because its path comes earlier in the AUT Path list.)
To map the application
myapplication to the path
squishserver --config addAUT myapplication /home/jane/bin
This way, if squishserver is given the name
myapplication to start, it will
not search all the paths in the AUT Path list, but
instead will use the mapped path and directly execute
It is just as easy to remove a mapping:
squishserver --config removeAUT myapplication /home/jane/bin
When a new test suite is created using the Squish IDE and the AUT is
specified in the New Test Suite wizard, behind the scenes, the Squish IDE
calls the squishserver with the
addAUT option to add
the new AUT as a mapped AUT.
The same can be done using the Squish IDE's Manage AUTs dialog (click | to invoke it). To add a mapped AUT to the Mapped AUTs, click on the Mapped AUTs item, then click the button and choose an AUT from the file dialog that pops up. Similarly, to remove a mapped AUT, expand the Mapped AUTs item, click the unwanted mapping, then click the button.
See also, the Manage AUTs dialog (Section 16.3.4).
Some applications, including Squish's tools, read environment variables and may alter their behavior depending on the environment. For example, an environment variable might be used to provide a path that may vary on different machines.
In the context of testing, there are two different environments to consider: The environment that the Squish tools (including test scripts) execute in, and the environment that the AUT executes in.
To set up Squish's environment (for the tools and for test scripts), we must set the relevant environment variables before running any Squish tools, so that when they are run they can detect the environment that has been created for them. The environment variables that Squish uses are described elsewhere (Environment Variables (Section 15.5)). Note that they only have to be set if you want to override the defaults.
When Squish records a new test or runs an existing test it provides
the AUT with an environment. This environment is based on the one that
Squish itself inherited from the operating system. This environment
PATH (on Windows),
LD_LIBRARY_PATH (Unix, but not Mac OS X), or
DYLD_LIBRARY_PATH (Mac OS X). This path is altered by
Squish and must not be deleted, although it is safe to append or
prepend additional paths to it. It is also possible to create
AUT-specific environment variables that Squish will set up for the
AUT—this is covered in the following subsection.
In some cases an application needs a special environment to be set up before it can be started successfully. This might include setting some environment variables, running a helper application, or checking for some other conditions (e.g., if there is enough memory available). Usually this is done by using a shell script or Windows batch file to do this pre-initialization work and which then starts the actual application. More information about such shell scripts and batch files is given in the section, Shell Scripts and .bat-Files as AUT (Section 15.3.4).
However, if all that is required to run an application successfully is to set up some environment variables, there is no need to create a shell script or batch file at all, since this can be handled by Squish. And in fact, the preferred approach when only environment variables are needed, is to let Squish take care of them.
Note that when the AUT is run it receives the environment that Squish provides for it.
To specify additional environment variables, open the Squish IDE's Settings view (Section 16.2.14), and scroll to the Environment area, as shown in the screenshot.
The values may themselves be or contain references to other environment
variables using the syntax
the screenshot illustrates.
The table always shows a blank row into which a new key (environment variable name) and value can be entered. Just click a cell in the table to start adding or editing a key or value. To delete a row, delete the key and click elsewhere.
Now, whenever the squishserver is told to run the AUT, it will first set up the environment in the normal way, then add the environment variables that identify the suite and test case, and then add any environment variables that we have set here, so that when the AUT starts it has the context we want.
|Squish vs. AUT Environment Variables|
Squish recognizes its own set of environment variables which can be set to affect aspects of Squish's behavior. Those that are used to control aspects of running and recording tests can be set in the Test Suite Settings dialog's Environment tab as described above. (For an example of such an environment variable, see Using an environment variable (Section 188.8.131.52.2) in Wrapping custom Java™ classes (Section 15.3.7).)
However, those environment variables that affect how Squish's IDE and command line tools behave must be set before running the Squish IDE or tools, and so cannot be set in the Test Suite Settings dialog; see Environment Variables (Section 15.5) for more about these environment variables, and also for details of how test scripts can access an AUT's environment variables.
It is also possible for test scripts to access environment variables; see How to Read Environment Variables inside Test Scripts (Section 13.15.3).
In situations where starting an application requires more than just setting up some environment variables (see Setting Environment Variables for the AUT (Section 184.108.40.206) for details), the best solution is to create a startup shell script or batch file to perform the necessary setup and to start the application, and to specify this startup script or batch file as the AUT, instead of the actual application's executable.
|Squish for Windows-specific (versions prior to 4.1)|
If you are using a version of Squish for Windows earlier than version
4.1 and want to use a batch (
Even when using a shell script as the AUT, it is still necessary to make the actual executable that will be run known to Squish. The reason for this is that Squish will only hook into programs started by the AUT that are white-listed, and when using a shell script as the AUT, the actual application binary, which Squish must hook into, will be started by the script and not directly by Squish. White-listing is easily done by simply adding the executable as known AUT to Squish by mapping its path or by adding its path to the AUT Path list—either method can be done in the Squish IDE or by using Squish's command line tools; see AUT Paths and Mapped AUTs (Section 15.3.2) for details.
On Unix and Mac OS X using a shell script works as expected—assuming the actual application's executable is known to Squish as mentioned in the note above.
On Windows, once the batch file is created, it is necessary to make one
small adjustment to the line where the application is started. To allow
Squish to hook into the application, the AUT must be started with a
small wrapper application called
The change is easy to make. Let's assume that the application we want to
test is called
myapp.exe. Normally we could run it
simply by putting its name in the batch file on a line of its own like
But to make it accessible to Squish we must run it from the wrapper, so we must change the line to this:
The environment variable,
SQUISH_PREFIX, is set if the AUT
was started through squishserver; it points to Squish's base
This will start
myapp.exe and allow
Squish to hook into it. But in practice you only want to do this 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" ( %SQUISH_PREFIX%\bin\dllpreload.exe myapp.exe ) ELSE ( myapp.exe )
myapp.exe will be run normally. To make
it run inside Squish's wrapper we must specify
-testing as an argument in the Test Suite
Settings dialog's Arguments field, so
that it will be passed to the AUT (the batch file in this case) by
Squish on startup.
Squish hooks into Java™ applications by providing a customized Java
VM shared library, the Squish Java VM. To make the standard Oracle Java™
and javaws.exe) use the Squish Java VM,
Squish sets the environment variable
to the directory of the Squish Java VM shared library file. The
standard Oracle Java™ launchers support this environment variable.
Unfortunately, Eclipse does not support the
JDK_ALTERNATE_VM mechanism, and so must be explicitly told
which VM to use. This is easily done by calling Eclipse with
For example, on Windows, instead of executing
we would do this instead:
eclipse.exe -vm "%JDK_ALTERNATE_VM%" -noSplash
Note that the
-vm option should be passed before any
There is no need to use the
-vm option when running an
Eclipse/RCP application using eclipse.exe
from within Squish, since Squish will automatically pass the
To test a Java™ applet, in the Test Suite
Settings dialog, specify the Java
appletviewer as the AUT (application under test),
and enter the URL of the HTML file containing the applet in the
Arguments field. Nothing more is required.
Additionally, using Squish for Web, it is also possible to test Java applets embedded in a web browser. See also Java Applets (Section 13.11.2) for details.
For testing Java™ applications launched via Java Web Start, in the
Test Suite Settings dialog, specify the Java
javaws as the AUT (application under test), and
-wait plus the URL to the JNLP file of
your web start application in the Arguments field.
Nothing more is required.
By default, Squish 3 wraps a predefined set of Java™ classes. Scripts can access the properties and methods on object instances only for these wrapped classes. Similarly, the Spy tool can only the show properties of wrapped classes. If a class isn't wrapped, only the properties and methods from the class's super classes (and then, only for those that are wrapped), can be accessed.
Squish 4 extend's Squish 3's functionality in this area by wrapping more classes, and also by dynamically wrapping AUT classes.
No matter which version of Squish is being used we might need to
access a class that for some reason isn't wrapped by default. One way of
doing this is to extend the list of wrapped classes, making additional
classes accessible just like the predefined wrapped classes. This is
done by creating a
.ini file that lists the classes
that must be wrapped, and then telling Squish's wrapper for the Java™
process where to find this file. This is discussed in a moment—
.ini file (Section 220.127.116.11).
The easiest way to access unregistered classes is to use Java's introspection capabilities. This is done in a few easy steps:
forNamemethod to get the class object for the class we want.
newInstancemethod to get an instance.
Here is an example (taken from the
test case) where we want to use the
java.text.SimpleDateFormat class even though Squish
doesn't wrap it by default and even though it isn't used in the AUT (and
so doesn't get dynamically wrapped).
AnyClass = calendar.getClass() SimpleDateFormatClass = AnyClass.forName( "java.text.SimpleDateFormat") formatter = SimpleDateFormatClass.newInstance() formatter.applyPattern("yyyy-MM-dd") test.verify(formatter.format(model.getStart()) ==
var AnyClass = calendar.getClass(); var SimpleDateFormatClass = AnyClass.forName( "java.text.SimpleDateFormat"); var formatter = SimpleDateFormatClass.newInstance(); formatter.applyPattern("yyyy-MM-dd"); test.verify(formatter.format(model.getStart()) ==
my $AnyClass = $calendar->getClass(); my $SimpleDateFormatClass = $AnyClass->forName( "java.text.SimpleDateFormat"); my $formatter = $SimpleDateFormatClass->newInstance(); $formatter->applyPattern("yyyy-MM-dd"); test::verify($formatter->format($model->getStart()) eq
set AnyClass [invoke $calendar getClass] set SimpleDateFormatClass [invoke $AnyClass forName \ "java.text.SimpleDateFormat"] set formatter [invoke $SimpleDateFormatClass newInstance] invoke $formatter applyPattern "yyyy-MM-dd" set minimumAllowed [invoke $formatter format [invoke $model getStart]] set minimumDate [invoke $formatter format [invoke $calendar getTime]] test compare $minimumAllowed $minimumDate
If this approach is used there is no need to create or register classes
.ini file. However, if you need to access a
lot of different unwrapped classes, using a
file might prove more convenient.
.ini file's format is illustrated by the
example below, which asks Squish to wrap two classes,
[general] AutClasses="com/example/product/Example", "com/example/product/Main"
The class names must be relative to the
also, that it is possible to wrap classes in Java™'s standard libraries
if they aren't wrapped by default, for example:
[general] AutClasses="java.util.Calendar","java.util.Date",\ "java.text.DateFormat","java.text.SimpleDateFormat"
When an extra class is wrapped, all super classes, classes from method arguments and return type classes will be wrapped as well.
In some cases it is possible that the wrapping could fail. If this
happens the class that failed to be wrapped will be identified as having
Unknown in the Spy tool.
Additionally, an extra
CLASSPATH can be set that might be
needed if the application extends its
execution. For example, when testing Java™ applets with Squish for Web,
CLASSPATH is extended by the
attribute of the
APPLET HTML tag. So,
continuing from the first example, a
can be added as shown below.
[general] AutClasses="com/example/product/Example", "com/example/product/Main" AutClassPath="demo.jar" AutClassBaseUrl="http://www.example.com/product/"
AutClassPath entry uses the same syntax as
CLASSPATH environment variable, with ';' (Windows) or
':' (Mac/Linux/Unix) used as separators. The entire value
must be quoted, as shown in the example.
It is also possible to set an
AutClassBaseUrl. This is
optional, but when set it adds a prefix to all paths in the
AutClassPath entry and the
itself is added to the
.ini has been created, the squishserver
can then be used to register it. The syntax of the command is:
squishserver --config setConfig <name-of-AUT> <path/file.ini>
Note the name of the application must be exactly the same as the name used in the Test Suite Settings dialog.
It is also possible to unregister a
removeConfig option with a very similar syntax to
squishserver --config removeConfig <name-of-AUT> <path/file.ini>
It is also possible to make use of a
without explicitly registering it with squishserver. This is done by
SQUISH_WRAPPER_CONFIG environment variable
(which can be done in the Test Suite Settings
dialog—see Setting Environment Variables for the AUT (Section 18.104.22.168)) and making its value the
path and filename of the
Squish can be told about native Windows controls simply by putting
some information into a suitable
.ini file. (This
is very similar in principle to how Java™ classes are handled; see
Wrapping custom Java™ classes (Section 15.3.7).)
It isn't necessary to create the file from scratch. Instead, copy the
winwrapper.ini file from Squish's
etc folder, and then modify this
file as described in the following sections.
|Registering the new INI file|
Once you have copied and modifed the
Using a copy of the
If you already have an
.ini file (perhaps because
you created one to work with Squish for Java™—as described
in Wrapping custom Java™ classes (Section 15.3.7)), you can use the existing file,
and simply add new Windows-specific lines to it. (Squish doesn't care
what the file's name is or where it is located, so long as it is a
.ini file that has the right information in the
By default, Squish will only record actions on native controls—such as embedded ActiveX controls—if it can clearly identify the controls as such. However, with Java™, it's not possible for Squish to be certain whether something is a native control or a Java™ control. In view of this, it is necessary to tell Squish about the native controls being used, so that Squish can correctly record actions on them.
For example, to inform Squish that a
MyCalendarCtrl is a native control, create a
configuration file as described in
Creating an INI file for Squish to recognize native Windows
controls (Section 22.214.171.124) with the following
[Windows Wrapper] Whitelist="MyCalendarCtrl"
|Native Control Names|
If you don't know the native control's class name, you will need to ask the application's developers. Alternatively, you can use a tool like Spy++ (which is supplied with Microsoft Visual Studio) or AutoIt Window Info.
It is possible to have more than one class listed in the Squish whitelist—just separate them with commas, and always put each name in quotes. For example:
[Windows Wrapper] Whitelist="MyCalendarCtrl","AnotherControl","InternetExplorerCtrl"
It is also possible to tell Squish to record events on native
Windows programs which are launched by your application. To do this, you
must tell Squish the window title bar caption used by the
Windows application which is launched, so that Squish knows that it
belongs to your main application. This is done by adding an
Windows entry to your
.ini file, for example:
[Windows Wrapper] Whitelist="MyCalendarCtrl","AnotherControl","InternetExplorerCtrl" Extra Windows="Microsoft Word"
Squish can be used to access all the properties exposed by ActiveX-based controls. This ActiveX functionality is also used to automate the controls supplied by various third-party vendors, such as Infragistics and Exontrol. This feature is disabled by default since it may incur a small runtime cost in performance and test stability, but it is easy to to activate it.
To activate the recognition of ActiveX controls—in fact,
recognition of all COM controls—edit the
file described in Creating an INI file for Squish to recognize native Windows
controls (Section 126.96.36.199) to add a
Object Detection entry, and give this entry a value of
1 to turn it on.
[Windows Wrapper] COM Object Detection=1