A common approach to testing Applications Under Test (AUTs) using different UI technologies is to have multiple editions of Squish installed. However, by default, each Squish IDE uses the same Eclipse workspace directory, so they can not be run side-by-side.
As a pre-sales engineer, I tend to switch between Squish editions often, but demo an AUT with the same name in each of them. For this reason, it makes sense for me to have separate server settings as well as separate workspaces for each Squish edition I am using.
For a customer who has to test multiple AUTs, multiple workspaces make it convenient to record script snippets on both AUTs without clobbering the workspace of each other.
This article explains different ways to start up Squish so that you can run multiple editions side-by-side.
Squish stores its settings in a directory that is different depending on the platform. On Windows, you can find it in
%APPDATA%\froglogic\Squish, while on Linux or MacOS, it can be found in
~/.squish. It is possible to use a different location by setting an environment variable,
What kind of information is stored in the Squish settings directory? Files located in the
paths.ini (information about global script directories and other paths) and
server.ini (server settings, which contain information about AUTs and their locations, and global script directory.)
By default, the workspace directory is stored under this location in a
Eclipse, and thus also the Squish IDE, stores information about the IDE settings and workspace in a folder that is called a workspace directory. This contains information to restore your windows, as well as your projects (test suites) to the state they were in when you quit or switched away from them, as well as other persistent settings. Due to file locking restrictions, two concurrent processes of Eclipse can not share a workspace, and this is why by default, running two Squish editions side-by-side is also not possible without changes.
The workspace directory can be customized by passing a
-data argument to
squishide from the command line.
Since the default workspace directory is under the User Settings directory, if
SQUISH_USER_SETTINGS_DIR is customized, the workspace directory will go under this location, too.
This approach is recommended when you have AUTs with the same name used in different editions of Squish.
Shared Server Settings, Separate Workspace
squishide -data tells the IDE to use a different workspace directory. If we do this for the different editions of Squish, we can run them side-by-side as well. In this case, they share the same Squish server settings.
Use this approach if the AUTs in different editions all have different names.
Example Linux Startup Script
This script, ‘
squishjava‘ will set up Squish for Java to use a separate user settings directory on Linux. Changing into the SQUISH_PREFIX directory before running
squishide is optional.
export SQUISH_PREFIX=/usr/local/squish/squish-for-java-6.5.2 export SQUISH_USER_SETTINGS_DIR=~/.squish-java cd $SQUISH_PREFIX ./squishide
Example Windows Startup Batch File
This file is called ‘
squish-win.bat‘ and is used to start the Squish IDE in a similar fashion for Squish for Windows. It also passes a
-data switch to
squishide, which tells the IDE to use a different directory for the Eclipse workspace and settings.
@echo off set SQUISH_USER_SETTINGS_DIR=%APPDATA%\Froglogic\Squish-Win set SQUISH_PREFIX="%USERPROFILE%\Squish for Windows 6.5.2" cd %SQUISH_PREFIX% squishide -data %USERPROFILE%\workspace\squish-win
SQUISH_USER_SETTINGS_DIR affects the IDE as well as the command line tools. Be sure to run the command line tools with the same desired environment if you wish to use them for the desired toolkit. This means you must make sure to set the command line environment to use the same variables when you are setting up batch-driven testing.
Changing the Squish IDE’s
-data location does not affect the behavior of command line tools, it is purely a switch for the IDE.
Managing multiple toolkits involves managing either the Eclipse workspace directory, or the Squish settings directory. Management of the workspace directory allows you to get back into work where you left off more easily. Management of all other server settings makes it possible to have AUTs with the same name used in different toolkits.
Each approach has its pros and cons, depending on whether your AUTs all have unique names.