Froglogic� Squish Launcher (squish.jar)

The Froglogic� Squish launcher allows interfacing with Squish tests.
It has been tested with Squish-3.4.4.

Configuration

The squish.xml file is just a template and must NOT be edited. It's used by the system to build dynamically the form that the user will be able to fill in from the GUI when creating a custom execution configuration.

Parameter	Description
General
Test root path	This must indicate where are located all the Squish tests. This is a root path. Each test in XStudio has a canonical path that will be appended to this path. This path MUST not include an ending slash. Default value is: `C:/`
Squish
Squish install path	This must indicate where is installed squish/ Default value is: `C:/tools/squish-web_win32`
Squish libraries path	This must indicate where are located the script commonly used by all squish test. This parameter is optional. Default value is: `C:/src/squish/lib`
Advanced
snooze factor	This must indicate the factor applied to all snooze calls (hence affecting the �time to replay�). The default value of 30% means that a snooze of 1 second in the script will actually last 300 ms. Default value is: `30 (%)`
Force kill squish squishrunner/_squishrunner processes after each testcase	If set to True, the squish runner will be killed (if still alive) by the launcher after the execution of each testcase. This should not be used in normal conditions. Default value is: `False`
Force kill squish squishserver/_squishserver processes after each test	If set to True, the squish server will be killed (if still alive) by the launcher after the execution of each test (including all testcases). This should not be used in normal conditions. Default value is: `False`
Force kill squish webhook/_webhook processes after each testcase (Squish for web)	If set to True, the squish webhook processes will be killed (if still alive) by the launcher after the execution of each testcase. This should not be used in normal conditions. Default value is: `False`
Force kill iexplore process after each testcase (Squish for web)	If set to True, all the iexplore processes will be killed (if still alive) by the launcher after the execution of each testcase. This should not be used in normal conditions. Default value is: `False`
Force kill ieuser process after each testcase (Squish for web)	If set to True, all the ieuser processes will be killed (if still alive) by the launcher after the execution of each testcase. This should not be used in normal conditions. Default value is: `False`

These values can be changed while creating the campaign session from XStudio.

Note about file path parameters:
Any parameter referring to a file or folder path (for instance Test root path) can be provided either using \ separator (if the tests are going to be executed on a Windows agent) or / separator (if the tests are going to be executed on a linux or MacOSX agent).

On windows, if you provide a path containing an OS-localizable folder such as C:\Program Files, always prefer the English version (i.e. NOT C:\Programmes if you're using a french-localized Windows) or the corresponding native environment variable (i.e. %PROGRAMFILES%).

Process

1) Each testcase in XStudio must have his dedicated squish script. The name of the script MUST be equal to tst_<testName>.
The tests are executed by the launcher using the following syntaxes:
First of all the squish server is run:
<squishInstallPath>/bin/squishserver.exe
Then, the test are executed:

<squishInstallPath>/bin/squishrunner.exe --testsuite <testRootPath>/<testPath> --testcase tst_<testName> --snoozeFactor <snoozeFactor> --reportgen xml,_tmp.xml

The launcher set an environment variable SQUISH_SCRIPT_DIR set to <squishLibraryPath> so that all libraries necessary for the main script to be executed are in the path.

Tutorial: Creating and executing Squish tests

In this tutorial, we will learn to run some Squish test scripts. We will use Squish for Java but this can be applied for any other squish application (Java, Qt, Web etc.)

Prerequisites

Install Squish for Java in the folder C:\\tools\\squish-3.4.4-java-win32
Create a file utils.js in the folder C:\\src\\squish\\lib the following content:


	function globalLog() {
	

	test.log("Global Log example", "Traces");
	

	}

Using Squish IDE create a new test suite (using javascript language, with no AUT application) called suite_fake in C:\\src\\squish\\testsuites.
In this directory, edit shared/scripts/objects.js and add the following content:


	function localLog() {
	

	test.log("Log example", "Some useful information");
	

	test.warning("Warning example", "Some warnings to highlight");
	

	}

Add to the testsuite, 2 tests:
tst_failure which contains the following code:


	function main() {
	

	source(findFile("scripts", "utils.js"));
	

	source(findFile("scripts", "objects.js"));
	

	
	globalLog();
	

	localLog();
	

	
	test.compare(1, 1);
	

	test.compare(2, 2);
	

	test.compare(3, 4);
	

	}

tst_success which contains the following code:


	function main() {
	

	source(findFile("scripts", "utils.js"));
	

	source(findFile("scripts", "objects.js"));
	

	
	globalLog();
	

	localLog();
	

	
	test.compare(1, 1);
	

	test.compare(2, 2);
	

	test.compare(3, 3);
	

	}

After these operations, the suite.conf file should contain:


AUT                = 
CLASS              = 
CLASSPATH          = 
CWD                = 
ENVVARS            = envvars
HOOK_SUB_PROCESSES = 1
LANGUAGE           = JavaScript
NAMINGSCHEME       = MULTIPROP
TEST_CASES         = tst_success tst_failure
USE_WHITELIST      = 1
WRAPPERS           = Java

You have now some very basic squish tests: one returning always a success and the other one a failure.

Create a dedicated category for Squish tests and create two tests

create a category Squish associated to the launcher squish.jar
under this category, create (somewhere in the tree) two tests with names success and failure with a canonical path set to suite_fake.

Creating a test campaign

create a campaign including the tests success and failure

create a campaign session with the default configuration settings.

Run a campaign session

Run the campaign session

Permissions

WARNING: if you're running your tests on Windows, it may be required to run the tests as administrator.
Having an account with Administrators permissions may even not be enough in some cases (especially if you're using Windows 10) and you may need to disable completely the UAC (User Access Control) on your computer.
To do so:

Press the Windows + R key combination
Type in regedit
Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
In the right-side pane, look for EnableLUA and set the value 0
Close the registry editor
Restart your computer

Debug

If your tests are not executed correctly or are reporting only failures, this is very likely because your configuration is incorrect or because you used a wrong naming convention for your tests and test cases.

The best way to quickly find out what's wrong is to look at the traces generated by XStudio (or XAgent).
The traces always include the detailed description of what the launcher performs (command line execution, script execution, API calling etc.) to run a test case. So, if you experiment some problems, the first thing to do is to activate the traces and look at what's happening when you run your tests.

Then, try to execute manually in a cmd box the exact same commands.
This will normally fail the same way.
At this point, you needs to figure out what has to be changed in these commands in order to have them run properly.

When you have something working, compare these commands to what's described in the Process chapter above. This will tell you exactly what you need to change.

Most of the time, this is related to:

some incorrect values in some parameters of your configuration,
the name of your tests,
the name of your test cases,
the canonical path of your tests

Launchers / Automated tests