Specifies where to print the text that would be shown in the Console view in the UI. Use stdout to print to STDOUT. Otherwise, the value is interpreted as a file path.

Specifies the test configuration to execute the tests. For example, "soatest.builtin://Demo Configuration"

Specifies the location of the Eclipse workspace to use for executing the tests. Defaults to a temporary directory.

Specifies the active data source within a data group. This parameter must be set to 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.

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

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 parameter to specify which data source contains the row associated with the tests you want to execute.

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 parameters. Note that if the specified environment is not found in the project, the default active environment will be used instead.

Specifies the active environment variables. This parameter must be set to 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.

Filenames, paths to files, or patterns that matches filenames to be excluded during testing. The pattern matching syntax is similar to that of Ant file sets. You can also specify a list of patterns by adding them to a .lst file. Example:

<excludes>
  <exclude>tests1/*.tst</exclude>
  <exclude>**/Test2.tst</exclude>
</excludes>

Fails the build by returning a non-zero exit code if any violations are reported.

Runs tests impacted by change. Parameter value specifies a path to the baseline coverage report.

The locations of projects to import into the workspace prior to executing tests. Defaults to ${project.basedir}. Example:

<import>
  <project>${user.home}/projects/project1</project>
  <project>${user.home}/projects/project2</project>
</import>

Filenames, paths to files, or patterns that matches filenames to be included during testing. The pattern matching syntax is similar to that of Ant file sets. You can also specify a list of patterns by adding them to a .lst file. Example:

<includes>
  <include>tests1/*.tst</include>
  <include>**/Test2.tst</include>
</includes>

Specifies an alternative Java runtime for starting SOAtest.

Disables building of projects before executing the tests.

Skip importing projects into the workspace.

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"

Allows you to configure settings directly. Settings passed with this parameter will overwrite those with the same key that are specified using the settings parameter. Example:

<properties>
  <report.dtp.publish>true</report.dtp.publish>
  <techsupport.auto_creation>true</techsupport.auto_creation>
</properties>

Enables publishing reports to DTP Report Center. DTP 5.3.x or later is required. The connection to DTP is configured in the settings file.

Refreshes the workspace, forcing it to resync with the file system.

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 HTML file for presenting the data. You can also configure SOAtest to generate a report in PDF or custom formats by specifying them in the report.format option. The option is specified in the settings file (see settings). If a path is not included as part the specified value, the report will be generated in the execution directory.

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

• <report>filename.xml</report>
• <report>filename.htm</report>
• <report>filename.html</report>

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 parameter and a file with this name already exists in the specified location, the previous report will be overwritten. If your parameter 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 parameter is not specified, reports will be generated with the default names "report.xml"/"html" in the current directory.

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 multiple resource parameters to specify multiple resources. All paths, including absolute paths, are relative to the workspace specified by the soatest.data parameter.

You can specify the following types of resources:

.tst file	Specify the path to a .tst file to execute all tests contained
directory	Specify the path to a directory in the workspace to execute all test suites in the directory.
.properties file	Specify the path to a .properties file and the value configured for the com.parasoft.xtest.checkers.resources property in the file will be interpreted as a colon-separated list of resources. Only one .properties file can be specified in this way.
.lst file	Specify the path to a .lst file and each line in the file will be treated as a resource. If no resources are specified on the command line, the complete workspace will be tested.
Team Project Set File (PSF)	PSFs are supported for SVN and other source systems, depending on the Eclipse plug-in capabilities installed.

Examples:

<resources>
  <resource>Acme Project</resource>
  <resource>/MyProject/tests/acme</resource>
  <resource>testedprojects.properties</resource>
</resources>

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

Specifies the path to the .properties file that includes custom configuration settings.

Prints detailed test progress information to the console.

Prints the current settings and customizations along with information regarding where they are configured (for example, in the settings.properties file).

Skips running SOAtest.

Specifies the location of the Parasoft SOAtest installation.

Specifies a .tst file name, path or pattern to be executed during testing. This pattern is added to the includes list, which is useful for debugging tests.

Specifies a testName parameter that matches 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.

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

<testFilters>
  <testFilter>
     <testName>WSDL Tests</testName>
  </testFilter>
</testFilters>

You can use more than one testFilter parameter to specify multiple tests: Use the substringMatch optional parameter to search for tests containing a specific string. In the following example, any tests that contain the string MyTest will run:

<testFilters>
  <testFilter>
     <testName>MyTest</testName>
     <substringMatch>true</substringMatch>
  </testFilter>
  <testFilter>
     ...
  </testFilter>
</testFilters>

If the test uses data from a data source, you can use the dataSourceRow and dataSourceName optional parameter to limit the range of data rows used to execute the test. for example:

<testFilters>
  <testFilter>
     <testName>MyTest</testName>
     <substringMatch>true</substringMatch>
     <dataSourceName>MyData</dataSourceName>
     <dataSourceRow>1</dataSourceRow>
  </testFilter>
</testFilters>

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

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

Specifies additional JVM options. Example:

<vmArgs>
  <vmArg>-Xmx8g</vmArg>
  <vmArg>-Dssl.debug=true</vmArg>
</vmArgs>

Limit the test scope to the resources that are associated with specific work items. Specify a list of work item IDs. Example:

<workItems>
  <workItem>TEST-7140</workItem>
  <workItem>TEST-16447</workItem>
</workItems>