applitools 

This option enables Selenic to integrate with Applitools. When set to true, the applitoolsApplicationName options are required.

Default is false.

applitoolsApplicationName

This option specifies the name of the application you are testing. The name specified is used in the App field in the Applitools web application UI so that you can filter by application.

This option is required if the applitools option is true .

captureDom

This option enables Selenic to capture the DOM when Selenium attempts to locate an element. This option is required for Selenic to automatically heal bad locators and/or generate recommendations for locators.

Default is false

collectCoverage

This option enables Selenic to collect coverage data for test impact analysis during test execution. Refer to Test Impact Analysis  for details.

Default is false 

coverageAgentHost

This option specifies the host where the AUT and coverage agent are running so that coverage data can be captured for test impact analysis during test execution. Refer to Test Impact Analysis  for details.

Default is localhost 

coverageAgentPort

This option specifies the port where the AUT and coverage agent are running so that coverage data can be captured for test impact analysis during test execution. Refer to Test Impact Analysis  for details.

Default is 8050

coverageAgentUserID

This option specifies a user ID so that different users can be distinguished when collecting coverage in multi-session mode. Refer to Test Impact Analysis for details. 

coverageDir

This option specifies a local directory for coverage data to be downloaded from the AUT server for test impact analysis during test execution. Refer to Test Impact Analysis  for details.

createApiTests

This option enables Selenic to create API tests using Parasoft SOAtest during UI test execution. 

Default is false

Only one .tst file can be created at a time if you enable this option. API tests will only be created when running tests sequentially. The following error will be shown when running tests in parallel:

[ERROR] ParasoftSelenicAgent - Failed to start web proxy session: A session is currently in
process. Wait for the session to finish before starting another one.

The test framework should be configured to run in a single thread (one test scenario at a time) in order to capture API tests for all test scenarios.

data

This option specifies the location of the data recorded during test execution. The -data option for the Selenic analyzer should be configured to match the value configured for this option.  

Default is <USER>/parasoft/recorded_data 

proxyPort

If you are creating API tests during UI test execution, specify the port number for the SOAtest Web Proxy.

Refer to the Parasoft Recorder SOAtest Smart API Test Generator documentation for additional information.

Default is 40090

soatestHost

If you are creating API tests during UI test execution, specify the host where the SOAtest server is running. 

Refer to the Parasoft RecorderSOAtest Smart API Test Generator documentation for additional information.

Default is localhost

soatestPort

If you are creating API tests during UI test execution, specify the port number for the SOAtest Server.  

Refer to the Parasoft RecorderSOAtest Smart API Test Generator documentation for additional information.

Default is 9080

secure

If you are creating API tests during UI test execution, this option enables Selenic to communicate with the SOAtest server over HTTPS.

Default is false

username

If you are creating API tests during UI test execution and user authentication is enabled for SOAtest server, this option specifies the user name for logging into the server.

password

If you are creating API tests during UI test execution and user authentication is enabled for SOAtest server, this option specifies the password for logging into the server.

maxSessionDaysToAnalyze 

This option indicates how many days worth of test sessions to include when applying the selfHealLocators option during execution. By default, there is no limit, so Selenic will analyze all available recorded data. 

In the following example, the Selenic agent will use 12 days worth of recorded data to determine the best option for automatically healing a failed locator or wait condition. 

maxSessionDaysToAnalyze=12 

The number of days refers to the most recent days for which data was recorded, regardless of how many calendar days have passed. 

maxSessionDaysToKeep 

This option indicates how many days worth of test session data to keep on disk.

Default is 90.

In the following example, the Selenic agent will keep 12 days worth of recorded data on disk:

maxSessionDaysToKeep=12 

The specified value refers to days for which data was recorded and not the number calendar days. 

screenshot 

This option enables the test machine to take a screenshot for any WebDriver commands Selenic logs.

You can set one of the following values:

• all  - A screenshot for each find element call in the Selenium test is captured
• failures  - Only screenshots for failing find element  calls are captured
• none  - No screenshots are captured

Default is none.

selfHealing

This option enables self-healing functionality. When set to true, the selfHealLocators and selfHealWaitConditions options are enabled. 

Default is false.

selfHealLocators

This option enables Selenic to automatically attempt to update a locator at runtime based on historical information collected during test execution. 

Default is true  when selfHealing is enabled.

selfHealWaitConditions

This option enables Selenic to extend Selenium wait conditions to prevent timeouts or other types of errors due to insufficient wait conditions during test execution.  

Default is true  when selfHealing is enabled.

additionalWaitTimePercent 

This option specifies how much additional time a wait condition should be extended to prevent a timeout or other errors related to insufficient wait conditions during test execution. The value specified with this option is a percentage of the original wait condition. Selenic will calculate the additional time based on the percentage and extend the Selenium tests' wait conditions. In the following example, a wait condition originally configured for 4 seconds will be extended by 50% to 6 seconds.  

additionalWaitTimePercent=50 

Default is 50  when selfHealing and selfHealWaitConditions are enabled.

minAdditionalWaitTime  

This option specifies a minimum number of seconds by which original wait conditions will be extended to prevent a timeout or other errors related to insufficient wait conditions during test execution. The value for this option overrides the value dynamically set with the additionalWaitTimePercent option if the resulting percentage is less than the minimum. 

Default is true  when selfHealing and selfHealWaitConditions are enabled.

sessionId

This option specifies an identifier for test execution data. This setting is optional and should only be used when running tests across multiple projects so that Selenium data from all projects can be grouped under a single session. Otherwise, Selenium data for each project will be recorded under separate session IDs. As a result, the analyzer will need to run for each test execution in a project before you can run tests in a different project.

Example:

mvn test -DargLine=-javaagent:/path/to/selenic_agent.jar=captureDom=true,sessionId=ID_1

When analyzing the data, use the -sessionId option when calling the selenic_analyzer.jar file to reference the ID set during test execution. For example:

java -jar /path/to/selenic_analyzer.jar -sessionId ID_1

By default, a date and time stamp is used.  

Selenic stores execution data in the directory specified with the data property. Each subdirectory within the recorded data directory contains execution data for individual sessions. The subdirectories are named with the sessionId value. If the sessionId parameter is not configured, Selenic will store the data in a subdirectory identified with a timestamp by default.

If you do not specify a session ID, then you must run the analyzer each time you run tests in a project before running tests in a different project. A session ID should be different for each test run so that results from an earlier test run to do get combined with later test runs. Therefore, using a build identifier or the default timestamp is recommended.