squishrunner
The squishrunner tool is used to execute and record test cases and test suites, and to set and retrieve the settings it needs at runtime. This section desribes its different modes of use:
--testsuite--record--info--config--testcase--help--version
Note: In almost every case, to make use of the squishrunner, a squishserver must already be running.
Every mode of use can accept zero or more server options. If the --host and --port options are not specified, Squish uses sensible defaults for them.
Server Options
| Option | Description |
|---|---|
--host host | By default, squishrunner connects to the squishserver on the local host (127.0.0.1). Use this option if you want squishrunner to connect to a squishserver running on a different machine. |
--port port | By default, squishrunner tries to connect to the squishserver on port 4322, which is also the port squishserver listens to by default. If you have told squishserver to listen on another port, use this option to tell squishrunner which port it should use when connecting to the squishserver. |
--debugLog commands | Outputs additional debugging information to the squishserver's debug log. |
Example
The following command executes all the test cases in the specified test suite and outputs all the additional debugging information that is available:
squishrunner --debugLog alpw --testsuite /home/reggie/squish_addressbook_py
Here, alpw is not a single command, but rather a list of one-letter commands: a, l, p, and w. Any of them can be specified, for example, ap, or w. The meaning of the letters are:
a– log the application's start. This is the same as checking the Squish IDE's Application Start checkbox in the Preferences dialog's Squish pane's Logging child pane.l– log dllpreload.exe (this only applies on Windows; if used on other platforms it is safely ignored).p– log the preload phase. This is the same as checking the Squish IDE's Hooking checkbox in the Preferences dialog's Squish pane's Logging pane.w– log the wrapping phase. This is the same as checking the Squish IDE's Wrapper Library checkbox in the Preferences dialog's Squish pane's Logging pane.
The suite.conf File
When the squishrunner is executed with the --testsuite option, it reads in the suite.conf file in the test suite's root directory, and its behavior will be affected by the specified options in those files. Many of these settings can be viewed and edited using the Squish IDE Test Suite Settings view.
| Option | Description |
|---|---|
AUT=aut [argument]* | The AUT to start for each test case, and optionally any command line arguments that should be passed to the AUT when it is started. This can be overridden on squishrunner's command line using the --testsuite and --testcase options' --aut option. The --aut option requires that the Automatically start the AUT option in the test suite settings is enabled. |
CLASSPATH | Sets the Java CLASSPATH in Squish for Java. |
CWD=pathOrMagic | The AUT's working directory when being tested. If this option isn't present or if its value is empty, the AUT's working directory is set to the path of the AUT's executable. If the value is not empty it is taken to be the path to use (e.g., C:\temp); unless it has one of two "magic" values. One magic value is <AUT_path> which means use the path of the AUT's executable (just the same as if the value were empty). Another magic value is <CWD_of_Server> which sets the AUT's working directory to the squishserver's working directory. This setting is normally set through the Squish IDE; see the Test Suite Settings view's Working Directory panel. |
ENVVARS=filename | A file that contains one or more lines of VARIABLE=VALUE pairs which define the environment variables and their values that should be in force during the AUT's execution. Squish will ensure that the environment is set up correctly before each run of the AUT. This can be overridden on squishrunner's command line using the --testcase option with the --record option, by using the --envvars option. Alternatively, when using the --testcase option with the --record option, it is possible to specify individual additional environment variables using one or more --envvar options. |
HOOK_SUB_PROCESSES=Boolean | Whether Squish should hook into sub-processes launched by the AUT. The Boolean should be true or 1 or false or 0. This setting is normally set through the Squish IDE in the Test Suite Settings view's Application Under Test (AUT) panel. |
IMPLICITAUTSTART=Boolean | Whether Squish should automatically start the AUT. This was common for Squish 3 scripts; but for Squish 4 this setting is normally false and the AUT is started in the test script using the ApplicationContext startApplication(autName) function. The Boolean should be true or 1 or false or 0. This setting is normally set through the Squish IDE in the Test Suite Settings view's Application Under Test (AUT) panel. |
LANGUAGE=language | The scripting language used by the test scripts. Currently this must be JavaScript, Python, Perl, Ruby, or Tcl. This can be overridden on squishrunner's command line using the --testcase option's --lang option. |
NAMINGSCHEME=scheme | If present, the naming scheme must be MULTIPROP or HIERARCHICAL. Normally it is best to use MULTIPROP (the default), except for Tk applications where HIERARCHICAL is used. |
OBJECTMAP=filename | By default, Squish reads the test suite's object map from the objects.map file in the root of the test suite's directory. If a different filename (with full path) is specified here, Squish will use the specified file instead of reading the default file. (This can be overridden on squishrunner's command line using the --testcase option when also using the --record option, by using the --objectmap option.)This configurating setting only applies to Text-Based Object Map. |
TEST_CASES=testcase [testcase]* | A space-separated list of one or more test case names. If the entire test suite is run, e.g., by using the --testsuite option without the --testcase option to specify test cases to run, every test case will be run. If every test case is run and this TEST_CASES option is set, the given test cases will be run first—in the specified order—followed by those test cases that aren't listed (if any).In addition, this option is used by the Squish IDE to determine the order in which the test cases are shown in the Test Cases view. To have only particular test cases run, use the |
WRAPPERS=wrappers | The wrappers which must be loaded for the tests to run successfully. Currently supported are Qt and XView. Additionally, a number of AUT-specific bindings libraries (application wrappers) to be loaded may be specified. This can be overridden on squishrunner's command line using the --testcase option's --wrapper options. Tests using Squish 4 should rarely need to use this option. |
The values used in the suite.conf file can also refer to environment variables. The syntax for this is $(ENVVAR). When such an entry is read, it is effectively replaced by the value of the environment variable of the same name. So if there was an environment variable called MAIL with value /var/spool/mail/reggie, if we used $(MAIL) in the suite.conf file, it would be replaced with /var/spool/mail/reggie.
squishrunner --testsuite: Running tests in batch mode
Use squishrunner with the --testsuite option to execute all of a test suite's test cases, or one or more specified test cases.
Usage
squishrunner [server-options] [settings-option] --testsuite test-suite-dir [other-options]
All items in square brackets are optional. The server-options are described in Server Options. The settings-option and other-options are discussed in the following sections. When used in this mode, the squishrunner's behavior is affected by the test suite's suite.conf. For more information, see The suite.conf File.
Settings Option
There is one deprecated settings-option:
- [
--settingsGroupsettingsGroup]
This option makes it possible to specify which settings group to use. Settings groups are deprecated and have no support in the Squish IDE. This option exists purely for backward compatibility.
Other Options
There are several other-options:
--local--resultdirresult-dir--reportgenreport-generator[,filename|dir]--testcase|--skip-testcasetest-case-dir*--interactive--abortOnFail--enable-video-capture--webbrowserbrowser--webbrowserargsargs--applauncherlauncher--launcherargsargs--deviceserial-number--exitCodeOnFailcode--snoozeFactorfactor--timeoutseconds--retrynumber--scriptargs[scriptargument]*--tagstags]*--random[sequence-number]--autaut [argument]*
The square brackets are not part of the syntax—they indicate optional items. Here, every option is optional, and some parts of some options are optional. The * indicates an option that can occur zero or more times, and | indicates alternatives.
See Playback option --testcase or --skip-testcase for more details on playback related options.
squishrunner --local: Start and stop a local squishserver
squishrunner can automatically start and stop a local squishserver process as needed, during the playback of a test suite. Using this option means no --host or --port options are needed, and no separate squishserver process needs to be started.
squishrunner --resultdir: Setting the Result Directory
The --resultdir option is used in combination with file-based report generators (stdout, xmljunit, xml2), and determines the location to save the test report and failed screenshot files, if any.
Note: This option conflicts with the use of a directory-based report generator (json, html, xml3) and specifying it will yield an error. In cases where a file-based and a directory-based report generator are combined (like junit and xml3) this option needs to be removed and the directory-based report generator will set it implicitly to the specified directory from its configuration.
squishrunner --reportgen: Generating Reports
Squish supports several report generators simultaneously, with one limitation, there can be at most one directory based generator.
Use squishrunner --help for a list of supported generators.
Some generators output to the console unless a destination is specified.
Note: Generally, it is recommended to use the latest version available for any report generator.
HTML report generator
Generates a static HTML page showing the results which are being stored in json data. This report generator is deprecated, please consider using the testcentercmd (see Processing Test Results) utility or the Squish Test Center report generator instead.
Note: This generator cannot be used together with the XML report generator or the JSON report generator.
squishrunner --testsuite test-suite-dir --reportgen html,report-dir
JSON report generator
Generates a Squish-specific custom JSON result format, intended to be used internally by the HTML report generator. This report generator is deprecated, please consider using the testcentercmd (see Processing Test Results) utility or the Squish Test Center report generator instead.
Note: This generator cannot be used together with the XML report generator or the HTML report generator.
json1.2(Squish 6.3 and newer)squishrunner --testsuite test-suite-dir --reportgen json1.2,report-dir
json1.1(Squish 6.1 and newer)squishrunner --testsuite test-suite-dir --reportgen json1.1,report-dir
json(Squish 6.0 and newer)squishrunner --testsuite test-suite-dir --reportgen json,report-dir
JUnit report generator
The junit generator outputs reports in the same format as JUnit tests do, as single file in XML format.
squishrunner --testsuite test-suite-dir --reportgen junit,reportfile.xml
The older xmljunit generator outputs reports in the same format as JUnit tests do, as single file in XML format. However, since it pre-dates Squish' BDD support it does not preserve the test case and BDD test structure in its generated test report as well as the junit report generator.
squishrunner --testsuite test-suite-dir --reportgen xmljunit,reportfile.xml
Null report generator
Generates no report, this is useful to not have the default stdout output.
squishrunner --testsuite test-suite-dir --reportgen null
stdout report generator
An ASCII plain text table, the default used by squishrunner when no other generator is specified.
squishrunner --testsuite test-suite-dir
or
squishrunner --testsuite test-suite-dir --reportgen stdout
The stdout report generator can accept an optional destination filename:
squishrunner --testsuite test-suite-dir --reportgen stdout,reportfile.txt
Squish Test Center report generator
For uploading to Squish Test Center.
squishrunner --testsuite test-suite-dir --reportgen testcenter,url/project/project-name?token=token
token is an upload token, created from Squish Test Center user settings. See Squish Test Center documentation for further details.
The full url can also include a query that specifies which labels or batches should be applied to the result. See Squish Test Center documentation for an example.
Excel spreadsheet report generator
squishrunner --testsuite test-suite-dir --reportgen xls,reportfile.xml
XML report generator
The XML report generator comes in a variety of versions, each newer one adding more detail. It is mainly used by internal tools and Squish Test Center, the generated report is not meant for manual browsing.
Note: This generator cannot be used together with the HTML report generator or the JSON report generator.
xml3.5(Squish 6.8 and newer)squishrunner --testsuite test-suite-dir --reportgen xml3.5,report-dir
Adds support for Video Capture. Also increases the precision of time attributes (now contains milliseconds).
xml3.4(Squish 6.5 and newer)squishrunner --testsuite test-suite-dir --reportgen xml3.4,report-dir
Allows seeing result attachments, screenshots, as well as script backtraces.
xml3.3(Squish 6.4 and newer)squishrunner --testsuite test-suite-dir --reportgen xml3.3,report-dir
Images can be seen in Squish Test Center.
xml3.2(Squish 6.3 and newer)squishrunner --testsuite test-suite-dir --reportgen xml3.2,report-dir
Uses a new <retry> tag, and reports retries for test cases and scenarios.
Given a test suite called suite_myapp, a test case called tst_case1, a report-dir called my_app_results, and assuming that an image verification point fails, squishrunner will write: my_app_results/results.xml and my_app_results/suite_myapp/tst_case1/verificationPoints/failedImages/failed_1.png.
Note: Legacy XML formats, such as xml3.1, xml3, xml2.2, xml2.1, xml2, and xml are kept for backward compatibility. Those older than xml3 take a filename instead of a directory.
Playback option --testcase or --skip-testcase
By default, all the test suite's test cases are executed, but if we want to specify exactly which test case or test cases are executed we can do so by supplying 1 or more of the --testcase test-case-dir option for each test case we want executed. Alternatively to the --testcase it's possible to skip test cases by using the --skip-testcase test-case-dir option.
Example
squishrunner --testsuite /home/reggie/suite_addressbook --testcase tst_add_address --testcase tst_edit_address
This example runs two specific test cases in the suite_addressbook suite. If we wanted to run all of the suite's test cases we would simply omit the two --testcase options since without them squishrunner defaults to running all of the suite's test cases. If we wanted to run all test cases but tst_add_address, we would do something like this:
squishrunner --testsuite /home/reggie/suite_addressbook --skip-testcase tst_add_address
Playback option --enable-video-capture
squishrunner will automatically start capture a video of the desktop of any application started via ApplicationContext startApplication(autName) or attached via ApplicationContext attachToApplication(autName). The videos are stored as part of the report, as if the test.startVideoCapture(message) function had been used and they are terminated once the application terminates or is disconnected from. The test report will have corresponding start and end entries when the capture starts and stops using a message that includes the application context's name.
Playback option --aut
By default, the AUT specified in the test suite's suite.conf file will be used for the execution of the test cases, along with any command line arguments that are specified there. However, we can override this by specifying the name of the AUT using the --aut aut option, followed by zero or more command line arguments. The specified AUT must be registered as a Mapped AUT already and the Automatically start the AUT option in the test suite settings must be checked/enabled. (See also, The suite.conf File.)
Playback option --interactive
By default, squishrunner works in non-interactive mode which allows it to run without access to any kind of graphical display. For using any of the testInteraction functions (See testInteraction Functions) however squishrunner needs to be run in interactive mode. Pass the --interactive option to enable interactive mode which will allow squishrunner to display dialogs and message boxes.
Playback option --abortOnFail
squishrunner with --testsuite option executes all test suite's test cases one by one. If the --abortOnFail option is specified, squishrunner will terminate the suite execution as soon as a failed test case is detected.
Playback option --webbrowser
When recording a web test, the browser to be used can be specified via the --webbrowser browser option. The browser can be any of: firefox (Firefox), ie (Microsoft Internet Explorer), edge (Microsoft Edge), safari (Safari), google-chrome (Google Chrome), or chromium-based (Chromium-based Applications).
Additionally, a --webbrowserargs option can be passed to invoke the chosen web browser with your choice of command line arguments.
Playback option --device
The --device option is for the Squish Android edition only. It is required when more than one Android devices connected and/or emulators running, to specify on which the application should be tested.
Playback option --snoozeFactor
Most modern tests use the Object waitForObject(objectOrName) function, but for various reasons some tests may have calls to the snooze(seconds) function. To influence the delay triggered by calls to the snooze(seconds) function, it is possible to use the --snoozeFactor factor option. The factor must be a number—if it is less than 1 (i.e., a decimal fraction, like 0.5), it will cause shorter delays, and if it is greater than 1 it will cause longer delays. A factor of 0 will produce the fastest possible execution.
Playback option --exitCodeOnFail
By default squishrunner returns non-zero value in case of fatal errors and 0 otherwise, regardless of the tests results. If --exitCodeOnFail option is set and defines the specific exit code (between 0 and 255), squishrunner will return the custom exit code on fatal errors or if any of the test cases has failed, and 0 otherwise.
Playback option --timeout
The --timeout option defines the amount of time (in seconds), after which a test case will be terminated regardless of its state. The option applies in --testsuite mode only and accepts positive integer values. After a test case is timed out, it terminates and the execution proceeds with the next text case, if any.
Playback option --retry
The --retry option defines the number of times Squish should try to execute a failed test case again (at maximum). This retrying of the current test case will end as soon as it passes. The option only applies to the --testsuite mode and accepts only positive integer values. For BDD tests the --retry option applies to every scenario of a feature.
Playback option --scriptargs
The --scriptargs option marks the end of squishrunner arguments. All following arguments are passed to the executed script which may process them. See OS.argv for an example of how to access the script arguments from a JavaScript array. Python's standard library offers sys.argv to do the same thing. Perl, Ruby and Tcl each have similar variables called @ARGV, ARGV, and $argv respectively.
Playback option --tags
The --tags option can be used to execute just those test scripts or BDD scenarios which match a given tag filter. The leading '@' sign from the feature file tags can be omitted. Some examples for the --tags option follows:
| Option | Description |
|---|---|
| --tags foo | Execute all scenarios or test scripts with the tag foo |
| --tags ~foo | Execute all scenarios or test scripts not tagged foo |
| --tags foo,bar | Execute all scenarios or test scripts tagged foo or bar (or both). |
| --tags foo --tags bar | Execute all scenarios or test scripts tagged both foo and bar. |
| --tags foo,bar --tags yoyo | Execute all scenarios or test scripts with the tag yoyo and one (or both) of foo and bar. |
For an example of how to @tag a BDD scenario, see this page.
Playback option --random
The --random option is for executing testcases in random order. The used sequence number is printed in the report as log message. If it is necessary to reproduce a specific order the sequence number can be given as parameter to the --random option. This can be used to reproduce a failure that occurs during random test execution. A sequence number of 0 indicates that a new sequence number is generated. It gives the same behavior as when the value for the option is omitted.
squishrunner --record: Recording a Test Case
Use squishrunner with the --testsuite and --record options to record a new test case in the test suite.
Usage
squishrunner [server-options] --testsuite test-suite-dir --record tst_test-case-dir [other-options]
All items in square brackets are optional. The server-options are described in Server Options. The other-options are discussed shortly. When used in this mode the squishrunner's behavior is affected by the test suite's suite.conf; see The suite.conf File. The tst_test-case-dir is the test case's name (and the directory where it will be stored)—it must start with tst_.
Example
squishrunner --testsuite /home/reggie/suite_addressbook --record tst_search_for_address --useWaitFor
This example will cause squishrunner to execute the AUT specified in the test suite's suite.conf file. All your interactions with the AUT will be recorded in the test suite's tst_search_for_address subdirectory in the test.py file (or in test.js, etc., depending on the language specified in the suite.conf file).
To save the recorded script file and exit squishrunner, press Ctrl+c.
We used the --useWaitFor option. This forces Squish to use the Object waitForObject(objectOrName) function rather than the snooze(seconds) function to provide the best possible playback reliability.
Other Options
There are several other-options:
--useWaitFor--testdatatestdata*--disableEventCompression--webbrowserbrowser--webbrowserargsarguments--autaut [argument]*
The square brackets are not part of the syntax—they indicate optional items. Here, every option is optional. The * indicates an option that can occur zero or more times.
Recording option --disableEventCompression
By default, squishrunner uses event compression during recording—this means that mouse moves and drags result in high-level API calls rather than lots of intermediate mouse hover and move events. If the --disableEventCompression is used, this compression is switched off. This option is only supported for Qt Widgets.
Recording option --webbrowser
The --webbrowser and --webbrowserargs have the same behavior in recording mode as in playback mode, please refer to Playback option --webbrowser.
Recording option --aut
By default, the AUT specified in the test suite's suite.conf file will be used for the recording of the test case, along with any command line arguments that are specified there. However, we can override this by specifying the name (with full path) of the AUT using the --aut aut option, followed by zero or more command line arguments—if any arguments are specified they will be passed to the AUT when it is started up. (See also, The suite.conf File.)
Executing a Test Case (Advanced)
Use squishrunner with the --testcase option to execute or record a specific test case. Using the --testsuite option is easier and more convenient than using this advanced option; see squishrunner --testsuite: Running tests in batch mode and Recording a Test Case.
Usage
squishrunner [server-options] --testcase tst_test-case-dir [other-options]
All items in square brackets are optional. The server-options are described in Server Options. The other-options are discussed shortly.
Keep in mind that the squishrunner needs to know various items of information to work correctly in --testcase mode. One way to ensure it has the information it needs is to specify each item individually using the --wrapper option, the --objectmap option, and so on.
Example
squishrunner --testcase tst_update_address --aut addressbook
This example starts the addressbook application and executes the specified test case. Since no language has been explicitly specified Squish will assume Tcl. Similarly, if the --record option is used, Squish will write Tcl. This can be changed of course, as we will see next.
Other Options
The square brackets are not part of the syntax—they indicate optional items. Here, every option is potentially optional. The * indicates an option that can occur zero or more times, and | indicates alternatives.
squishrunner will assume that the scripting language (to execute, or to record) is Tcl unless the --lang language option is used. If the script does not have a call to ApplicationContext startApplication(autName), then the --aut aut option must be used to specify the AUT.
| Option | Description |
|---|---|
--record | Records the test case. Without this option, the test case will be executed. |
--explicitAutStart | Includes a call to the ApplicationContext startApplication(autName) function into the recording. This is useful for Test Suites created by the Squish IDE, which do not automatically start the AUT when executing a testcase. |
--testdata testdata* | Zero or more test data files. |
--lang language | Changes from Squish's default scripting language (Tcl) to the specified language: JavaScript, Python, Perl, Ruby, or Tcl. |
--disableEventCompression | By default, squishrunner uses event compression during recording. This means that common event sequences result in high-level API calls rather than lots of low-level events. This option switches off the compression, which is not recommended. |
--snoozeFactor factor | Most modern tests use the Object waitForObject(objectOrName) function, but for various reasons some tests may have calls to the snooze(seconds) function. Use this option to influence the delay triggered by calls to the snooze(seconds) function. The factor must be a number. If it is less than 1 (i.e., a decimal fraction, like 0.5), it will cause shorter delays. If it is greater than 1, it will cause longer delays. A factor of 0 will produce the fastest possible execution. |
--reportgen report-generator[,filename] | Squish can output a report detailing what happened during test case execution. Several different report generators are supported. Use this option to specify the one to use, along with the file into which the report should be written. For example, --reportgen xml3.5,/tmp/results. Notice the comma (,) which is essential. For a list of all report-generator formats, see squishrunner --reportgen: Generating Reports. |
--wrapper wrapper* | One or more wrappers needed by the test case. |
--envvars filename | The test case's entire environment. The filename specifies the full path to a file that has key=value entries, one per line, and that will be set as environment variables. |
--envvar key=value* | Overrides one or more environment variables. |
--cwd @app|@server|path | By default, squishrunner will use the current working directory when executing or recording the test case. Use @app to use the AUT's directory as the working directory instead. Use @server to use squishserver's directory or path to specify an explicit absolute path. |
--objectmap filename | When using Text-Based Object Map, the object map must be loaded by the test case itself using the objectMap.load(filename). Alternatively, you can use this option to specify the full path of the object map to read (if executing or recording a test) or create or append to (if recording a test). |
--webbrowser browser | The browser to use when executing a web test: firefox (Firefox), ie (Microsoft Internet Explorer), edge (Microsoft Edge), safari (Safari), google-chrome (Google Chrome), or chromium-based (Chromium-based Applications). |
--webbrowserargs arguments | Invokes the chosen web browser with command line arguments. |
--interactive | By default squishrunner works in non-interactive mode which allows it to run without access to any kind of graphical display. To use any of the testInteraction functions, squishrunner needs to be run in interactive mode. Use this option to enable interactive mode, which will allow squishrunner to display dialogs and message boxes. |
--aut aut [argument]* | If the test case doesn't use the ApplicationContext startApplication(autName) function, the AUT (with full path) must be specified using this option, followed by zero or more command line arguments. If any arguments are specified, they will be passed to the AUT when it is started up. |
Querying for Information
Use squishrunner with the --info option to query for various items of information.
Usage
squishrunner --info topic
Example
This will print a list of the registered AUTs and their paths on the console:
squishrunner --info applications
Topics
The following table describes the information that is output for each of the available topic values. As is usual for squishrunner, a squishserver should be running for squishrunner to work.
| Option | Description |
|---|---|
androidDevices | A list of all attached Android emulator or device instances. |
androidInstrumentation | A list of all installed instrumentation packages on all attached Android emulator or device instances. |
applications | A list of all the applications which are located in the squishserver's application paths and that can be tested by Squish with the current settings. |
attachableApplications | A list of all the registered attachable applications. |
autPaths | A list of paths in which squishserver looks for applications when starting an AUT. This value can be changed by using the --config addAppPath or --config removeAppPath option of squishserver. See Configuring squishserver. |
AUTPMTimeout | How many milliseconds Squish should wait after an application has exited to end squishrunner. In some setups, a second process is started from the first one and the second Squish hookup happens after the first one has exited. This value can be changed by using the --config setAUTPostMortemTimeout option. See Configuring squishrunner. |
AUTTimeout | How many seconds squishrunner will wait before timing out with a test failure if the AUT doesn't respond after being started. This value can be changed by using the --config setAUTTimeout option. See Configuring squishrunner. |
cursorAnimation | on, if the mouse cursor should be animated (visually moved between positions) during script playback. Otherwise, off. This value can be changed by using the --config setCursorAnimation option. See Configuring squishrunner. |
defaultWebBrowser | The name of the web browser that is used for web testing. |
iosSimulatorDevices | A list of available iOS simulator devices. Requires squishserver to run on a macOS machine with Xcode installed. |
javaPath | Installation prefix of the Java installation squishserver was configured to use. This value can be changed by using the --config setJavaVM option of squishserver (which requires a path to the Java executable, not its installation prefix). See Configuring squishserver. |
responseTimeout | The number of seconds that Squish will wait before timing out with a test failure during (mostly network based) communication between the squishserver and the squishrunner, and also between other Squish components. |
settingsKey (deprecated) | The settings key for this Squish installation, e.g., ver1. |
webBrowsers | A list of all the system's web browsers that were detected. |
wrappers | A list of the installed wrappers. |
Configuring squishrunner
Use squishrunner with the --config option to change various squishserver settings. In addition to the --config, you must also specify the --host and --port of the squishserver. Using squishrunner to configure squishserver is useful when the squishserver is not running on the local machine. Under the covers, it is squishserver that performs the actual configuration changes for you.
Usage
squishrunner --config action
Only a single configuration action can be specified each time.
Example
squishrunner --config setAUTTimeout 60
This will set the AUT timeout to 60 seconds (the default is 20 seconds).
Actions
| Option | Description |
|---|---|
--config addAUT aut path | Adds an application mapped to the specified path. If different versions of the same application have the same executable name and appear in different paths that have been registered using the addAppPath option, this option specifies the one that Squish should use, thereby avoiding any ambiguity. |
--config removeAUT aut | Removes an application. |
--config setBaseDir wrapper directory | Creates a new wrapper with the given wrapper name and base directory. |
--config setBrowserPath browser executable | A browser and the path to its executable. The browser should be one of: firefox (Firefox), ie (Microsoft Internet Explorer), edge (Microsoft Edge), or safari (Safari), chromium-based (Chromium-based Applications), and the executable should include the full path to the browser's executable. |
--config addInitScript wrapper script | The filename of a Tcl script that should be executed when the specified wrapper is used. The script should either be a filename with an absolute path or a filename with a path relative to the wrapper's base directory. Whenever a test case needs to use a wrapper, Squish first executes all the scripts registered with this action for the wrapper (if any), before the test case is executed. Although init scripts must be written in Tcl, they are only used to initialize GUI toolkit wrappers, and have no effect on what language we use to write our test scripts. |
--config setAUTTimeout seconds | How long Squish should wait before timing out with a test failure if the AUT doesn't respond after being started. This action's current setting can be output using the --info AUTTimeout option. See Querying for Information.) |
--config setResponseTimeout seconds | How long Squish should wait before timing out with a test failure during (mostly network based) communication between the squishserver and the squishrunner, and also between other Squish components. |
--config setAUTPostMortemTimeout milliseconds | How long Squish should wait after an application has exited to end squishrunner. In some setups, a second process is started from the first one and the second Squish hookup happens after the first one has exited. |
--config setCursorAnimation on|off | Whether the mouse cursor should be animated (visually moved between positions) during script playback (on) or not (off). This action's current setting can be output using the --info cursorAnimation option. See Querying for Information. |
--config setDefaultWebBrowser browser | For web applications, specifies the default web browser: firefox (Firefox), ie (Microsoft Internet Explorer), edge (Microsoft Edge), safari (Safari), google-chrome (Google Chrome), or chromium-based (Chromium-based application). |
--config addAttachableAUT aut [host:]port | The AUT that should be attached to when the test case is run. |
--config removeAttachableAUT aut [host:]port | Unregisters an AUT that was previously registered using the addAttachableAUT action. |
--config isBrowserExtensionInstalled browser-id browser-executable | Verifies that the extension for the browser-id is installed and enabled and the extension version allows automation with this Squish version. This option currently supports using firefox and google-chrome for the browser-id. The command will output its results to the command window from where it is being invoked. If you have multiple browser installations on your system or Squish cannot find the browser by itself, you can provide the browser-executable as a second argument. |
--config installBrowserExtension browser-id browser-executable | Installs the browser extension needed to automate the browser identified by browser-id. The installation procedure will start the browser and point it to the extensio. The browser will then request your permission to install and activate the extension. Eventually, it will require you to restart the browser. Once all of this has completed, make sure to completely quit the browser by using the Quit menu entry. This option currently supports using |
--config getGlobalScriptDirs | A list of currently set GlobalScript locations. |
--config setGlobalScriptDirs dir1,dir2,dir3,... | GlobalScript locations, which will be included when interpreter searches for source(findFile()) includes. Several comma-separated locations can be given. |
© 2023 The Qt Company Ltd.
Documentation contributions included herein are the copyrights of
their respective owners.
The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation.
Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property
of their respective owners.