Every mode of use can accept one or more of these server option arguments:

The square brackets are not part of the syntax—they indicate optional items. Here, every option is optional.

By default squishrunner connects to the squishserver on the local host (127.0.0.1). Use the --host host option if you want squishrunner to connect to a squishserver running on a different machine.

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 the --port port option to tell squishrunner which port it should use when connecting to the squishserver.

The --host and --port options are optional—Squish will use sensible defaults if they aren't specified.

squishrunner --debugLog alpw --testsuite /home/reggie/squish_addressbook_py

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. Note also that many of these settings can be viewed and edited using the Squish IDE (see Test Suite Settings view (Section 8.2.16).)

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.

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 (Section 7.4.3.1). The settings-option and 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 (Section 7.4.3.2).

There is one deprecated settings-option:

The square brackets are not part of the syntax—they indicate that this option is optional. 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.) Since the option was not used in the example above, the default settings were used in that case.

There are several other-options:

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 (Section 7.4.3.7) for more details on playback related options.

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.

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. There is no need to use this option in combination with report generators (xml3, html) that take a directory as an argument.

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.

	Use the latest version
	Generally, it is recommended to use the latest version available for any report generator.

squishrunner --testsuite <test-suite-dir> --reportgen html,<report-dir>

squishrunner --testsuite <test-suite-dir> --reportgen junit,<reportfile.xml>

squishrunner --testsuite <test-suite-dir> --reportgen xmljunit,<reportfile.xml>

squishrunner --testsuite <test-suite-dir> --reportgen null

squishrunner --testsuite <test-suite-dir>

squishrunner --testsuite <test-suite-dir> --reportgen stdout

squishrunner --testsuite <test-suite-dir> --reportgen stdout,<reportfile.txt>

squishrunner --testsuite <test-suite-dir> --reportgen testcenter,<url>/project/<project-name>?token=<token>

squishrunner --testsuite <test-suite-dir> --reportgen xls,<reportfile.xml>

7.4.3.6.8. 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.

• 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.

	Legacy XML Formats
	Older formats (xml3.1, xml3, xml2.2, xml2.1, xml2, xml) are kept for backward compatibility. Those older than xml3 take a filename instead of a directory.

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

squishrunner will automatically start capture a video of the desktop of any application started via startApplication or attached via attachToApplication. The videos are stored as part of the report, as if the test.startVideoCapture 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.

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 (Section 7.4.3.2).)

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 (Section 6.3.18)) 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.

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.

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.

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.

Most modern tests use the waitForObject function, but for various reasons some tests may have calls to the snooze function. To influence the delay triggered by calls to the snooze 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.

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.

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.

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.

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.

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:

For an example of how to @tag a BDD scenario, see this page.

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.

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 (Section 7.4.3.1). 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 (Section 7.4.3.2). 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).

Notice that we used the --useWaitFor option. This forces Squish to use the waitForObject function rather than the snooze function to provide the best possible playback reliability.

There are several other-options:

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.

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.

The --webbrowser and --webbrowserargs have the same behavior in recording mode as in playback mode, please refer to Playback option --webbrowser (Section 7.4.3.12).

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 (Section 7.4.3.2).)

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 (Section 7.4.3.3) and squishrunner --record: Recording a Test Case (Section 7.4.3.21).

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 (Section 7.4.3.1). 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. (And similarly, if the --record option is used, Squish will write Tcl. This can be changed of course, as we will see next.)

There are many 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 startApplication, then the --aut aut option must be used to specify the AUT.

If the --record option is used the test case will be recorded; otherwise it will be executed.

If the --explicitAutStart option is used a recording will include a call to the startApplication function. This is useful for Test Suites created by the Squish IDE which do not automatically start the AUT when executing a testcase.

Zero or more --testdata testdata files may be specified.

To change from Squish's default scripting language (Tcl), use the lang language option, where language is one of JavaScript, Python, Perl, Ruby, or Tcl.

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. If the --disableEventCompression is used the compression is switched off. Using this option is not recommended.

Most modern tests use the waitForObject function, but for various reasons some tests may have calls to the snooze function. To influence the delay triggered by calls to the snooze 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.

Squish can output a report detailing what happened during test case execution. Several different report generators are supported, and the one to use along with the file into which the report should be written can be specified using the --reportgen report-generator,directorypath option. 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 (Section 7.4.3.6)

If the test case needs one or more wrappers these can be specified by using a --wrapper wrapper option for each one.

The test case's entire environment can be specified using the --envvars filename option where 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.

It is also possible to add or override one or more environment variables by using one or more --envvar key=value options.

By default, squishrunner will use the current working directory when executing or recording the test case. But this can be overridden by using --cwd @app which tells squishrunner to use the AUT's directory as the working directory, or by --cwd @server which says to use squishserver's directory, or by --cwd path where we specify an explicit absolute path.

When using Text-Based Object Map (Section 7.11.5), the object map must be loaded by the test case itself using the objectMap.load function, but it can also be specified using the --objectmap filename option where the filename specifies the full path of the object map to read (if executing or recording a test) or create or append to (if recording a test).

When executing 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.

If the test case doesn't use the startApplication function, the AUT (with full path) must be specified 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.

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 (Section 6.3.18)) 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.

Use squishrunner with the --info option to query for various items of information.

Usage:

squishrunner --info topic

The topic may be any one of: wrappers, applications, AUTTimeout, cursorAnimation, settingsKey, attachableApplications, webBrowsers, defaultWebBrowser, responseTimeout, androidDevices, or androidInstrumentation.

Example:

squishrunner --info applications

This will print a list of the registered AUTs and their paths on the console.

Here is a description of the information that is output for each of the available topics. (As is usual for squishrunner, a squishserver should be running for squishrunner to work.)

If the wrappers topic is specified, squishrunner will print out a list of the installed wrappers.

If the applications topic is specified, squishrunner will print out 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.

If the AUTTimeout topic is specified, squishrunner will print out 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 using the --config setAUTTimeout option; see Configuring squishrunner (Section 7.4.3.27).)

If the cursorAnimation topic is specified, squishrunner will print “on” if the mouse cursor should be animated (visually moved between positions) during script playback; otherwise it will print “off”. (This value can be changed using the --config setCursorAnimation option; see Configuring squishrunner (Section 7.4.3.27).)

If the settingsKey topic is specified, squishrunner will print the settings key for this Squish installation, e.g., “ver1”.

If the attachableApplications topic is specified, squishrunner will print a list of all the registered attachable applications.

If the webBrowsers topic is specified, squishrunner will print a list of all the system's web browsers that it has detected.

If the defaultWebBrowser topic is specified, squishrunner will print the name of the web browser that it uses for web testing.

If the responseTimeout topic is specified, squishrunner will print 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.

If the androidDevices topic is specified, squishrunner will print a list of all attached Android emulator/device instances.

If the androidInstrumentation topic is specified, squishrunner will print a list of all installed instrumentation packages on all attached Android emulator/device instances.

Use squishrunner with the --config option to change various settings.

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).

Many actions are supported:

Use the setBaseDir action to create a new wrapper with the given wrapper name and with the given base directory.

Use the setBrowserPath action to specify 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.

Use the addInitScript action to specify 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.)

Use the setAUTTimeout action to specify 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 (Section 7.4.3.26).)

Use the setResponseTimeout action to specify 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.

Use the setAUTPostMortemTimeout action to specify 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.

Use the setCursorAnimation action with an argument of on or off to specify whether the mouse cursor should be animated (visually moved between positions) during script playback. (This action's current setting can be output using the --info cursorAnimation option; see Querying for Information (Section 7.4.3.26).)

For web applications use the setDefaultWebBrowser action to specify the default web browser. 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 application).

Use the addAttachableAUT action to specify an AUT that should be attached to when the test case is run.

Use the removeAttachableAUT action to unregister an AUT that was previously registered using the addAttachableAUT action.

Use the isBrowserExtensionAvailable option to verify whether the extension for the browser-id is installed, enabled and the version allows automation with this version of Squish. 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 executable as another argument.

Use the installBrowserExtension option to install the browser extension needed to automate the browser identified by browser-id. The installation procedure will start the browser and point it to the extension, the browser will then request your permission to install and activate the extension and 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 firefox and google-chrome for the browser-id. If you have multiple browser installations on your system or Squish cannot find the browser by itself you can provide the executable as another argument. The command will output its results to the command window from where it is being invoked.

The getGlobalScriptDirs prints out a list of currently set GlobalScript locations.

Use the setGlobalScriptDirs option to define GlobalScript locations, which will be included when interpreter searches for source(findFile()) includes. Several comma separated locations can be given.

Additional Note: Use squishrunner --help to get a list of any options and actions which your currently used Squish package actually supports.

Use squishserver with no command line options, or with those documented here, to have a server for squishrunner to use.

Usage:

squishserver [--quiet] [--verbose] [--configfile configfile] [--host address] [--port port] [--local] [--listenfile listenfile] [--daemon [--logfile logfile]] [--disable-presence]

The items in square brackets are optional.

squishserver can be used with no options at all, or with a --port port to specify which port to listen on. The command line option overrides any PORT=port that is specified in the squishserverrc file.

Another useful option is an --host host to specify the IP address to listen on. The default is is to accept connections on any IP address assigned to the machine where squishserver is running.

If the --verbose option is used, squishserver will produce more output than usual. The extra output is designed to be helpful for investigating problems such as remote server connection problems or incorrect Qt library path settings.

On Unix-like platforms (i.e., not on Windows), the --daemon option can be specified. If this option is used then the squishserver will be run in the background. This means that the server will detach itself from the controlling terminal and stop printing anything to standard output or to standard error. Anything that the AUT prints to these channels will be lost, unless also the --logfile with full path to a file name is given. There is no point using the --verbose option when the --daemon option is used without a log file. (The squishserver also supports a --local option in this mode; it exists for backward compatibility and should not be used now.)

To stop a squishserver from running use the --stop option.

Usage:

squishserver --stop [--host address] [--port port]

If the port isn't specified the server will be contacted using Squish's default port number.

Example:

squishserver --stop

This tells the squishserver to shut down. (In almost all use cases, a squishrunner cannot operate without a squishserver.)

Use squishserver with the --config option to change various settings.

Usage:

squishserver --config action

Most of these configuration commands operate on the server.ini file by default, which is in ver1 of the Squish User Settings Directory. You can provide the location of a different configuration file by using the --configfile option.

Usage:

squishserver [--configfile /path/to/myserver.ini] --config action

Only a single configuration action can be specified each time. (For backward compatibility an additional optional option, --settingsGroup settingsGroup is supported. If specified it tells the squishserver which settings group to use. The Squish IDE has no support for settings groups and this option is deprecated.)

Example #1:

squishserver --config addAppPath C:\squish\examples\qt4\addressbook

This will add the C:\squish\examples\qt4\addressbook path to Squish's list of paths in which to look for AUTs.

Note that it is possible to refer to environment variables on the command line using the syntax $(NAME) (although on some shells—typically those used on Unix—the $() parts may need to be escaped).

Example #2.

squishserver --config addAUT addressbook $(SQUISHPATH)/examples/qt4/addressbook

Here we have added a new AUT and to do so we have used the SQUISHPATH environment variable—which must have been set earlier.

Many actions are supported:

Use the addAppPath action to add a path to the list of paths in which squishserver looks for applications when starting an AUT.

Use the removeAppPath action to remove a path from the list of paths in which squishserver looks for applications when starting an AUT.

Use the addAUT action to add 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 --config addAppPath option then which one should Squish use? By using the --config addAUT option, we can say specifically which executable should be used in which path thereby avoiding any ambiguities.

Use the removeAUT action to remove an application mapped to a specified path.

Use the addAttachableAUT action to specify an AUT that can be attached to.

Use the removeAttachableAUT action to unregister an AUT that was previously registered using the addAttachableAUT action.

Use the setWrapperLibs action to specify the wrapper library or libraries to use with the specified AUT.

Use the usesBuiltinHook to force Squish to use a built-in hook rather than the default non-intrusive hooking. Be sure to read about this option before using it—see Using the Built-in Hook (Section 7.13.2).

Use the setAUTTimeout action to specify how many seconds Squish should wait before timing out with a test failure if the AUT doesn't respond after being started. The default is 20.

Use the setResponseTimeout action to specify how many seconds Squish should wait before timing out with a test failure when waiting for a response from the AUT. The default is 300. (This is distinct from the timeout used by the waitForObject function.)

Use the setHardExitTimeout action to specify how many milliseconds squishserver should maximally wait after sending a SIGTERM to an application, before sending a SIGKILL if the application is still running. (The time is on top of setSoftExitTimeout.) This option does nothing on Windows. The default is 100 milliseconds.

Use the setSoftExitTimeout action to specify how many milliseconds squishserver should maximally wait after squishrunner has ended before killing the application if it is still running, when started automatically or with startApplication. The default is 2000 milliseconds.

Use the setAUTPostMortemTimeout action to specify how many milliseconds Squish should wait after the first AUT process has exited. This applies to AUTs that actually start the "real" AUT as a new/separate (sub-)process, like Java Web Start, but also third party Java application launchers. In those cases the first AUT process may exit before the second (the "real") AUT process has been hooked up by Squish. And this will cause Squish to abort its attempt to start (and hook up) the AUT with an error - unless hooking of the second AUT process succeeds within the number of milliseconds specified by this setting. The default is 1500.

Use the setBrowserPath action to specify a browser and the path to its executable. The browser should normally be one of firefox (Firefox), ie (Microsoft® Internet Explorer), edge (Microsoft® Edge), or safari (Safari), chromium-based (Chromium-based application), and the executable should include the full path to the browser's executable.

Squish supports specific web browsers on specific desktop platforms out of the box. However, it is also possible to test other web browsers or test on non-desktop platforms (e.g., iPhones and similar) by using Squish's web proxy (Web Proxy (Section 7.4.8)).

All the following configuration actions are specific to Java™ AUTs.

Use the setJavaVM action to tell Squish where the Java executable is located, giving it the full path (e.g., /usr/lib/jvm/java-6-sun/jre/bin/java on Linux).

Use the setLibJVM action to tell Squish where the Java virtual machine is located, giving it the full path (e.g., /usr/lib/jvm/java-6-sun/jre/lib/i386/client/libjvm.so on Linux).

Use the setJavaVersion action to specify a particular version of Java to use (e.g., 1.5.0_11).

For Java™ AUT's using the SWT GUI library, the SWT library to use should be specified using the setSWTJar action and giving the full path to the .jar file (e.g., C:\swt\swt.jar on Windows).

Use the setConfig action to register a custom .jar file that implements Squish's Java Extension API. (See Java Extension API for Custom Widgets (Section 6.7.4).)

Use the removeConfig action to unregister a custom .jar file that implements Squish's Java Extension API. (See Java Extension API for Custom Widgets (Section 6.7.4).)

The squishserver has some other configuration options, specifically, usesBuiltinHook and setJavaHookMethod; these are for backward compatibility; they should not be used now.

Usage:

startaut [--verbose] [--wrapper=toolkit] [--cwd=working-directory] [--capture-output] --port=port aut [aut-command-line-options]

or:

startaut [--verbose] [--wrapper=toolkit] [--cwd=working-directory] --uses-builtin-hook aut [aut-command-line-options]

Usage:

androidobserver [--device serialNumber] [--port port] [--clear-app-settings] [--force-rotation rotation] [--attach-port attachPort] [--no-autostart-observer] [--no-ui-automation] [--web-hookup-timeout msec] [-e key value]* aut

Usage:

startjavaaut [--verbose] [--cwd=directory] --port=port aut [aut-command-line-options]

The --verbose option is only useful for debugging the tool itself and is not normally used. The --cwd option is used to specify the AUT's working directory. The --port option is used to specify the port number that Squish should use for communicating with the AUT. Naturally, the aut must be specified and must be a Mapped AUT (Section 7.3.2.2) name. Any aut-command-line-options options are passed to the AUT when the startjavaaut program starts it.

startwinaut can be used to start an AUT as a child process, or to attach to an already running one, depending on the options that are used. Usage:

startwinaut --port=port [--aut-timeout=seconds] (--window-title=title of window | --pid=Process ID of AUT | [--cwd=directory] command [command-line-options])

Note

When startwinaut is started in a console window (such as the one of cmd.exe) with the --window-title option and wildcards, it is possible that the console window is found instead of the desired target window. This is because the console window title may change to the executed command. It is possible to overcome this by using the "start" command built into cmd.exe to start startwinaut with a new, separate console window which does not have a dynamic window title: c:\> start $SQUISHDIR/bin/startwinaut --window-title=somewindow

The available arguments are described below: