System Property Reference

Java Web Start places restrictions on the system properties that can be defined in a JNLP file. Any system property prefixed with javaws. is allowed. All the system properties listed below can also be set with the javaws. prefix, and indeed this prefix is required when launching Iridium from Java Web Start. The javaws. prefix can be (and usually is) omitted if running Iridium from a JAR directly, and must be omitted if running Iridium via Gradle.

System properties marked as * are required.


Defines the username used when running tests against BrowserStack. This takes precedence over the details in the configuration file.

See Remote Testing for details on the BrowserStack configuration.


Defines the access token used when running tests against BrowserStack. This takes precedence over the details in the configuration file.

See Remote Testing for details on the BrowserStack configuration.



When set to true (the default is false), remote tests run in Browserstack will download the video of the test into the reports directory.


Specify the location of the configuration XML file.

This option accepts a complete file path, or a URL.


Specify the location of the data set collection XML file.

This option accepts a complete file path, or a URL.

testSource *

Path to E2E tests.

If this is a directory, it will be scanned for .feature files that have a matching entry in the #FeatureGroup: comment which equals the featureGroupName setting.

If it is a file or a URL, the script is run disregrading the featureGroupName setting.


When the feature file is hosted on a web server and includes #IMPORT comments, the importBaseUrl setting defines where the imported fragments are found.

For example, running the following

java \
    -DtestDestination=Marionette \
    -DtestSource=parent.feature \
    -importBaseUrl= \
    -DappURLOverride= \
    -jar /Users/Shared/IridiumApplicationTesting.jar

will load the feature file, and then load any
fragments references by #IMPORT comments from


Name of the browser to run the tests (Chrome, Firefox, IE). Select BrowserStack to run the tests remotely in BrowserStack.

Valid options are:

  • CHROMESECURE - An instance of Chrome with features like the File API, microphone and webcam disabled (available since 1.0.33)
  • CHROMEHEADLESSSECURE - A headless instance of Chrome with features like the File API, microphone and webcam disabled (available since 1.0.33)
  • CHROMEFULLSCREEN - Launches Chrome in a full screen view (available since 1.0.34)
  • CHROMESECUREFULLSCREEN - Launches Chrome in a full screen view features like the File API, microphone and webcam disabled (available since 1.0.34)
  • IE
  • EDGE


This is optional, and is only used when testSource references a directory.
It links to the featureGroupName attribute on a feature element.

The featureGroup system property is also a mapping between a feature script and the urls and data sets that will be applied to it. For example, you might have a configuration file like this:

        <featureGroup name="Google">
                <url name="default"></url>

And you can run your script with the featureGroupName system property set like this:


Which would allow you to run a feature that opens the page defined as part of the feature group with the step Given I open the application:

Feature: A feature group test
  Scenario: Do Google Search
    Given I open the application
    And I populate the element with the name of "q" with "Search Term"
    And I click the element found by "Google Search",, webdriver.edge.driver or webdriver.opera.driver, webdriver.gecko.driver

Path to web drivers for those browsers


When set to false (the default is true), this property will prevent Iridium from extracting and using the supplied webdriver executables.

This may be useful if your antivirus program flags these executables as dangerous, as it means you can download the drivers for yourself, exclude them from the antivirus scan individually, and then reference them with the,, webdriver.edge.driver, webdriver.opera.driver or webdriver.gecko.driver system properties.

You can download webdriver executables from the following links:








Defines the location of the Firefox executable that is to be used for tests.


The location of the Opera executable.


This defines the group that a BrowserStack capabilities profile needs to belong to in order to be included in the test.

Groups usually indicate the browser (IE, Chrome etc), OS (Windows, MacOS etc) or device kind (Desktop, Mobile etc).

This is useful when you want to limit your tests to a logical group of device or platform.


Tick this option to leave the browser window open after the local tests have been completed.
This is useful when you want to continue using the web application from where the script finished up.

This has no effect when tests are run in BrowserStack.

If you select the "Leave Browser Open" option, you may find that some resources are not released when the test is finished and the application is closed. In particular, the chromedriver and operadriver processes are left in memory (depending on the browser you are using). If you run a number of tests in succession, these processes can take up quite a bit of memory, and it is up to you to kill them manually.

Also be aware that you will need to disable the BrowserMob and Zed Attack proxy via startInternalProxy if you intend to leave the window open and continue to use the browser. This is because if BrowserMob is enabled, the browser will be configured to use the proxy, but the proxy will be closed when Iridium shuts down, and no browser requests will work. Disabling the proxy means you can continue to use the browser window after Iridium has been closed.


The appURLOverride system property can be used to define the default URL that the application will open with.

The appURLOverride system property is essentially a shorthand for the appUrlOverride.default system property. See the appUrlOverride.<name> system property for more details.

This is useful if want want to test a feature branch with a test script, or if you want to test custom query params.

Because you are specifying a single URL, the test will be run once.

Note that you can only override the default URL when the test script does not reference a named url. For example, this line in a test script will fail if appURLOverride is defined, because these named url references from the configuration file are no longer loaded.

And I open the application "app"

In the above case you must use a configuration file or define all named urls using appURLOverride.<name> system properties.

The appURLOverride system property takes precidence over the appURLOverride.<name> system properties, and any named URLs in the configuration file.


The appURLOverride system property is essentially a shorthand that allows you to define the single default URL used in steps like:

And I open the application

For situations where a number of named application URLs are required, each can be defined as a appURLOverride.<name> system property. The name of the app used in a step like

And I open the application "app"

matches the <name> in the system property like

The default URL used in the step And I open the application is defined in the system property appURLOverride.default.

The appURLOverride.<name> system property takes precidence over any named URLs in the configuration file, but are ignored if the appURLOverride system property is defined.


This defines the maximum number of entries that will be selected from the data set.
Usually when testing locally you'll set this to one to ensure that you are only opening one instance of an application.


In order to improve the performance of the tests, they can be run in parallel. This setting defines the maximum number of threads that Cucumber will be run in. Keep in mind that when you run tests in BrowserStack, there is a limit (probably 2) of the number of parallel tests. You will get errors if you set this value higher than the maximum number of parallel tests when running in BrowserStack.

NOTE: Running cucumber in separate threads does not mean that local browsers are running in their own "sandbox".

It is quite likely that running two or more threads for the same web application in the same browser will result in those browser instances conflicting with each other as they edit the same server session.

When running locally against a single instance of an application (i.e. running multiple data sets against a single application), it is usually best to use a single thread.


See the Writing tests chapter to get more information about this option.

NOTE: Be aware that this system property includes semicolons, which may has special meaning when used with shells like Bash. You may need to escape these characters when running from the command line.


When running a local test, enabling this option will save a screen capture to an AVI file.
The location of the AVI file is displayed in the output window once the test is finished.

This currently doesn't work when ZAP is enabled.


When set to true, screenshots will be taken at the end of each scenario. This is useful when
running tests against a headless browser like PhantonJS, as it gives you an opportunity to see
the state of the web page at points during the test.


When set to true, a screenshot will be taken if there is an error in the script.


When set to true, the HTML report will be opened once the test is finished.


This property can be set to a custom folder that will host the report files generated by Iridium. This setting overrides the saveReportsInHomeDir setting.


When set to true, all report files and screenshots will be saved in a folder in the users home
directory. Otherwise the files are saved in the current working directory.

You almost always want to set this to true when running tests locally, and set it to false when
running tests in Bamboo.


Sets the PhantomJS logging level. PhantomJS will generate a lot of unnecessary log messages while waiting for elements to be displayed, so by default the logging is turned off. But it can be handy to see these messages sometimes, so setting this value to something like WARN will give you some additional logging.


This property takes a comma separated list of proxies to enable or disable. The BrowserMob proxy is enabled by default, which means this property effectively has a default value of browserMob.

You enable a proxy by including it in the list. You disable a browser by including it in the list prefixed with a dash.

For example, to enable the Zed Attack Proxy, set this value to zap e.g.


To disable the BrowserMob proxy, set this value to -browserMob e.g.:


To enable ZAP and disable BrowserMob, set this value to zap,-browserMob e.g.:



Defines the host name or ip address of an external proxy to pass requests through


Defines the port used by the external proxy


Sets the username used to connect to the external proxy. Note that BASIC is currently the only supported authentication scheme.


Set the password used to connect to the external proxy. Note that BASIC is currently the only supported authentication scheme.


Set the realm or domain of the upstream proxy. Right now this is only used when ZAP is enabled, as BrowserMob does not support NTLM authentication. See the Proxies chapter for more details.


When set to true, a new Selenium WebDriver instance will be created with each new scenario. When set to false (which is the default), the WebDriver instance will be reused across the entire feature.


When set to true (which is the default), once a scenario fails, all subsequent scenarios will also fail. When set to false, each scenario will be executed regardless of whether others before it have failed.


This property defines how many times Iridium will attempt to run a suite of tests after detecting an failure. This was introduced to work around issues such as browsers crashing. Specifically PhantomJS 2.1.1 has been observed to crash frequently enough to warrant a retry of the test.


The time, in seconds, that will elapse between test retries. It defaults to 0, meaning tests will be retried immediately.


Set this property to true to configure Iridium to return immediately from each step. This means that no actions will be taken by any step.

This is useful for validating the syntax of a feature file.


Set this to false (it defaults to true) to have cucumber report it's progress in color in the terminal.


Set this to false to disable any automated workarounds implemented by Iridium for browser driver inconsistencies.

Defaults to false.


Set this to false to disable the generation of a JUnit XML report file.

Defaults to true.


Set this to false to disable the generation of a HTML report file.

Defaults to true.


Set this to true to enable the generation of a JSON report file.

Defaults to false.


Set this to true to enable the generation of a text report file.

Defaults to false.


Sets the maximum time that Iridium will run for in milliseconds. This is useful to ensure that Iridium does not execute long run scripts in resource constrained environments.

moveCursorToElement (experimental)

Setting this system property to true will move the mouse cursor to the element that is being interacted with. This gives the illusion that the interaction with the browser is done via the mouse, and is more effective at demonstrating the actions someone would have to take to replicate a test script.

Note that certain APIs in Selenium have not been implemented yet that would make this feature work as expected. The org.openqa.selenium.interactions.internal.Coordinates.onScreen() method has not been implemented, which means there is no way to find the screen location of a web element.

The workaround is to launch the test in Chrome full screen mode. All other browsers at this point can not be used with the moveCursorToElement system property.

results matching ""

    No results matching ""