-appconsole

Prints verbose output. To print output to a file, run -appconsole <FILE_PATH>. To print output to stdout, run -appconsole stdout. 

The same type of output that would be shown in the console (if running from the GUI) is printed.

-config

Specifies the test configuration you want to use to execute the tests. This parameter is required.

The value specified is interpreted as a URL, the name of a test configuration, or the path to a local file.

By filename example: 

-config "mylocalconfig.properties"

By URL example: 

-config "http://intranet.acme.com/SOAtest/team_config.properties"

Built-in configurations examples:

-config "builtin://Demo Configuration"
-config "Demo Configuration"

User-defined configurations example:

-config "user://My First Configuration"

Team configurations examples:

-config "team://Team Configuration"
-config "team://teamconfig.properties"

-data

Specifies the location of the Eclipse workspace directory to use for executing the tests. The default value is the current user’s dependent directory. If the option is not used, then the default workspace found under <SOATEST_WORKSPACE>\parasoft\workspace will be used, for example, C:\Users\<USER>\parasoft\workspace.

-dataGroupConfig

Specifies the active data source within a data group. This argument must be followed by the location of an XML file that specifies the active data source for each data group within each .tst file contained in the test run. The XML file must use the following format:

<tests>
	<test> <!--1 or more-->
		<workspacePath></workspacePath>
		<dataGroups>
			<dataGroup> <!--1 or more-->
				<dataGroupName></dataGroupName>
				<activeDataSourceName></activeDataSourceName>
			</dataGroup>
		</dataGroups>
	</test>
</tests>

The <workspacePath> element for datagroupConfig and environmentConfig should contain the path to the resource (for example, .tst) in the workspace, not the path on the file system. You can right-click the .tst file in the SOAtest UI and choose Properties to get the correct path to the resource. For example, the path in the following example is /SOAtest Tutorial/Calculator.tst.

-dataSourceName 

Specifies the name of the data source associated with the test(s) you want to run. See -dataSourceRow for additional information.

-dataSourceRow 

Runs all tests with the specified data source rows(s). You can specify a list of row numbers or row ranges. The following values are examples of valid values:

• 5 
• 1,2,5 
• 3-9 
• 2-5,7,20-30

You can also specify all as the value to force all data source rows to be used, even if the data sources were saved to use only specific rows.

You can use the -dataSourceName option to specify which data source contains the row associated with the tests you want to execute. The -dataSourceName argument is optional, but it must come after -dataSourceRow if it is used.

-encodepass

Generates an encoded version the specified value. The encoded string will print to the console and the command line application will terminate. We strongly recommend using this option to generate safe strings that you can use to connect to DTP or License Server. Example:

soatestcli -encodepass mypassword -config "builtin://Example Configuration"

Must be used with -config. 

-environment 

Specifies the name of the SOAtest environment to use for executing the tests. An environment in SOAtest is a set of variables that define endpoints and other test-specific inputs. SOAtest environments should not be confused with environment entities as described in Virtualize and Continuous Testing Platform. 

When running functional tests from the command line, you can override the active environment specified in a project with one specified from the command line. Note that if the specified environment is not found in the project, the default active environment will be used instead.

-environmentConfig

Specifies the active environment variables. This argument must be followed by the location of an XML file that specifies the environment variable values to use for each .tst file contained in the test run. The XML file must use the following format:

<tests>
	<test> <!--1 or more-->
		<workspacePath></workspacePath>
		<Environment>
			<Variable> <!--1 or more-->
				<Name></Name>
				<Value></Value>
			</Variable>
		</Environment>
	</test>
</tests>

The <workspacePath> element for datagroupConfig and environmentConfig should contain the path to the resource (for example, .tst) in the workspace, not the path on the file system. You can right-click the .tst file in the SOAtest UI and choose Properties to get the correct path to the resource. For example, the path in the following example is /SOAtest Tutorial/Calculator.tst.

-exclude

Specifies a filename, path to a file, or pattern that matches filenames to be excluded during testing. The pattern matching syntax is similar to that of Ant file sets. The following wildcards are supported:

• * (single asterisk): matches any character
• ? (question mark): matches 0 or 1 of the preceding character 
• ** (double asterisk): matches any directory.  

Examples:

• -exclude **/internal/** (test everything except classes that have path with folder "internal")
• -exclude **/*Test.xml (test everything, but files that end with Test.xml)

-fail

Fails the build by returning a non-zero exit code if any violations are reported. The return code will be 2 for static analysis violations, 4 for functional test violations, 8 for code review violations, and 1 for any other problem.

Also see CLI Exit Codes.

-help

Displays a list of valid command line options.

-ignoreMissingResources 

Enables the test execution to ignore missing resources and proceed with the resources present at runtime. If this option is not used, then all resources specified with the -resource option must be present for the test run to execute.  

-impactedTests 

Limits the tests that are run to only those impacted by changes in the AUT. When this option is used, you can use the -include and -exclude arguments to further affect what tests are run:

• -include: Specifies tests that should always be run regardless of whether or not they are part of -impactedTests.
• -exclude: Specifies tests that should not be run regardless of whether or not they are part of -impactedTests.

See Executing Tests Impacted by Change for more information.

-import

Imports the specified Eclipse project(s) into the Eclipse workspace without copying project files. Imported projects will reference files in their original locations. Specifying a .project file imports the selected project. Specifying a directory imports all Eclipse projects found in the selected directory and its subdirectories.

Examples:

• -import .project
• -import c:\DevelRootDir\

To import multiple projects or sets of projects, run soatestcli -import multiple times. Attempting to use multiple -import flags with soatestcli will result in an error. After importing all necessary projects, you can run soatestcli without the -import option to execute tests.

-include

Specifies a filename, path to a file, or pattern that matches filenames to be included during testing. The pattern matching syntax is similar to that of Ant file sets. The following wildcards are supported:

• * (single asterisk): matches any character
• ? (question mark): matches 0 or 1 of the preceding character 
• ** (double asterisk): matches any directory.  

Examples:

• -include **/Bank.xml (test Bank.xml files)
• -include **/ATM/Bank/*.xml (test all .xml files in folder ATM/Bank)
• -include c:/ATM/Bank/Bank.xml (test only the c:/ATM/Bank/Bank.xml file)

You can also specify a list of patterns by adding them to a .lst file using the -include option to specify the .lst file. For example, you could save the following patterns to a file called include.lst and specify -include c:/include.lst and SOAtest will treat each line in the file as a single pattern: 

**/Bank.xml
**/ATM/Bank/*.xml
c:/ATM/Bank/Bank.xml

The effects that specifying the include.lst file achieves the same as the following command:

-include **/Bank.xml -include **/ATM/Bank/*.xml -include c:/ATM/Bank/Bank.xml"

-installcertificate 

Installs the Parasoft Root Certificate Authority, which enables SOAtest to record HTTPS traffic. The certificate is usually installed during the normal installation process (see Installation), but can be reinstalled with this option if necessary. Example usage:

soatestcli.exe -installcertificate

-J 

Specifies additional JVM options, which are passed to the Eclipse executable via the -vmargs option.

The Eclipse -vmargs option is used to customize the operation of the Java VM to use to run Eclipse. If specified, this option must come at the end of the command line. Even if not specified on the executable command line, the executable will automatically add the relevant arguments (including the class being launched) to the command line passed into Java using the -vmargs argument. Java Main then stores this value in eclipse.vmargs.

Usage is -vmargs [vmargs*] (Executable, Main)

-machineid

Prints the machine ID. The machine ID is used for licensing purposes.

-prefs 

Specifies an Eclipse workspace preferences file to import. The specified value is interpreted as a URL or the path to a local Eclipse workspace preferences file. The best way to create a workspace preferences file is to use the Export wizard. To do this:

1. Go to File > Export.
2. In the Export Wizard, choose Preferences and click Next.
3. Do one of the following:
   • To add all of the preferences to the file, choose Export all.
   • To add only specified preferences to the file, choose Choose specific preferences to export and enable the preferences you want to import.
4. Click Browse... and indicate where you want the preferences file saved.
5. Click Finish.

We recommend deleting properties that are not applicable to SOAtest and keeping only critical properties, such as the classpath property. We also recommend that you replace machine/user-specific locations with variables by using the $(VAR) notation. These variables will be replaced with the corresponding Java properties, which can be set at runtime by running soatestcli with  -J-D options (for example soatestcli -J-DHOME=/home/user).

Examples:

• -prefs "http://intranet.acme.com/SOAtest/workspace.properties"
• -prefs "workspace.properties"

-property

Allows you to configure a single setting directly in the command line. Use the following format: key=value.

You can use this option multiple times to configure several settings on the same command line. Earlier entries with the same key will be overwritten. Additionally, settings passed with this option will overwrite those with the same key that are specified using the -settings option, regardless of their order in the command.

Example:

• -property session.tag=sa_linux -property report.dtp.publish=true -property techsupport.auto_creation=true

This option can be used to import settings into the GUI from the command line using the executable that starts SOAtest or Virtualize (for example, soatest.exe, virtualize.exe, or eclipse.exe). When used in this manner, the settings that you specify replace those currently in the workspace. For example: 

soatest.exe -property report.dtp.publish=true

-publish 

Enables or disables publishing reports to DTP Report Center. DTP 5.3.x or later is required.

The connection to DTP is configured in the settings file.

-refresh

Refreshes the workspace, forcing it to resync with the file system. This is particularly important if you have made changes to the workspace outside of the workbench.

-resource

Specifies the path to the test suite(s) to run. To run a single test suite, specify the path to the .tst relative to the workspace. To run all test suites within a directory, specify the directory path relative to the workspace. Use the option multiple times in the command to specify multiple resources. Use quotation marks when the resource path contains spaces or other non-alphanumeric characters. All paths, including absolute paths, are relative to the workspace specified by the -data parameter.

You can specify the following types of resources:

Examples:

-resource "Acme Project"
-resource "/MyProject/tests/acme"
-resource testedprojects.properties

If you are specifying multiple tests from different projects, tests will be grouped project-by-project, in the order specified in the multiple -resource parameters or in the .lst file.

All tests in the same project as the first resource will be run before any tests in a different project. If you specify resources in the order the following order, for example:

/ProjectA/A.tst, /ProjectB/B.tst, /ProjectA/C.tst 

they will be executed in the following order:

1. /ProjectA/A.tst
2. /ProjectA/C.tst
3. /ProjectB/B.tst.

-report

Generates a report and saves it with the name and path specified. The report includes an XML file containing the report data, as well as an HTML report (or one or more reports in other formats, if specified using the report.format option in the settings file (see -settings)) for presenting the data. If a path is not included as part the specified value, the report will be generated in the execution directory.

All of the following commands will produce an HTML report filename.html and an XML report filename.xml.

• -report filename.xml
• -report filename.htm
• -report filename.html

If the specified path ends with an ".html"/".htm"/".xml" extension, it will be treated as a path to the report file to generate. Otherwise, it will be treated as a path to a directory where reports should be generated.

If the file name is explicitly specified in the command and a file with this name already exists in the specified location, the previous report will be overwritten. If your command doesn’t explicitly specify a file name, the existing report file will not be overwritten; the new file will be named repXXXX.html, where XXXX is a random number.

If the -report option is not specified, reports will be generated with the default names "report.xml"/"html" in the current directory.

-router 

Specifies an argument to search for in the test suite and a value to replace it with.

In the following example, the URI specified with searchURI is replaced by the value specified with replaceURI:

-router searchURI:host1.adobe.com replaceURI:host2.adobe.com  

In the following example, searchURI matches all URIs and replaces them with the value specified with replaceURI:
-router searchURI:* replaceURI:http://host2.adobe.com/service

This option only applies for SOAP clients.

This feature is deprecated. Use Environments instead.

-settings

Specifies the setting file used to configure execution preferences. The settings in this file specify details, such as DTP settings, email settings, and license settings. Settings with the same key that are specified with the -property option will overwrite those passed with this option, regardless of their order in the command.

The setting file is a properties file. These files can control reporting preferences, who should reports be sent to, how should those reports be labelled, what mail server and domain should be used, and so on.

This option can be used to import settings into the GUI from the command line using the executable that starts SOAtest or Virtualize (for example, soatest.exe, virtualize.exe, or eclipse.exe). When used in this manner, all settings in the properties file replace those currently in the workspace. For example: 

soatest.exe -settings <path to properties file>

For details on creating settings files, see Settings Files - Options.

-showdetails

Prints detailed test progress information to the console.

-showsettings

Prints the current settings and customizations along with information regarding where they are configured (for example, in the settings.properties file). See Configuring Settings for the list of settings you can configure.

-startServer

Starts the SOAtest server. This argument should be used by itself without other CLI options related to test execution such as -config.

-testName 

Specifies a string that matches the name or part of the name of a test to run. SOAtest searches for tests in the resource that contain the string specified, but programmatic pattern matching, such as wildcards or regex, is not performed. Use quotation marks if the test contains spaces.

In the following example, a test or test suite named WSDL Tests will run:

soatestcli.exe -data "C:\workspace" -resource "MyService.tst" -config "user://Example Configuration" -testName "WSDL Tests"

Use the match: qualifier to search for tests containing a specific string. In the following example, any tests that contain the string MyTest will run: 

soatestcli.exe -data "C:\workspace" -resource "MyService.tst" -config "user://Example Configuration" -testName match: MyTest

You can use more than on -testName flag to specify multiple tests:

soatestcli.exe -data "C:\workspace" -resource "MyService.tst" -config "user://Example Configuration" -testName "name1" -testName "name2"

If the test uses data from a data source, you can use the dataSourceRow: and dataSourceName: parameters immediately following a match: parameter to limit the range of data rows used to execute the test. The dataSourceName: argument is optional, but it must come after dataSourceRow: parameter if it is used, for example:  

soatestcli.exe -data "C:\workspace" -resource "MyService.tst" -config "user://Example Configuration" -testName match: "MyTest" dataSourceRow: 1 dataSourceName: "MyData" 

The value for the dataSourceRow: parameter can be specified as a single row or a range of rows. The following values are examples of valid values:

• 5 
• 1,2,5 
• 3-9 
• 2-5,7,20-30

 The dataSourceRow: and dataSourceName: parameters are also available as standalone options. See -dataSourceRow and -dataSourceName.

-visualStudio

Report test results to Microsoft Visual Studio Team System. Allows you to send results back to Microsoft Visual Studio Team System. For details, see Using Microsoft with SOAtest.

-version

Displays the SOAtest version number.

-workItems

Specifies a comma-delimited list of work item IDs. The test scope will be limited to the resources that are associated with those work items. See Working with the Requirements View for additional information.

-Zjava_home 

Specifies an alternate JRE to use when starting SOAtest. When not used, SOAtest starts with a default instance of Java shipped with the product. See Configuring Java Runtime for more information.