Skip to content

Configuring Intern

Jump to bottom
csnover edited this page Oct 5, 2014 · 6 revisions

An Intern configuration file is a standard AMD module. The configuration module to load is specified using the config argument on the command-line (for Node.js) or the config argument in the URL query string (for browsers).

For an example of a default Intern configuration, you may look at the included example configuration file.

Note that some options have been changed or removed in Intern 2. See the Intern 2 release notes for more information.

Configuration Options

capabilities

A set of default capabilities that will be applied to all environments being tested. These capabilities can be overridden per-environment in the environments array. Different services like BrowserStack and Sauce Labs may have different sets of capabilities:

Please note that extra options for ChromeDriver are specified as capabilities: { chromeOptions: { /* options here */ } }.

The name capability will be filled in with the module ID of the configuration file being used. The build capability will be filled in with the current commit ID from the TRAVIS_COMMIT environment variable automatically, if it exists.

Default: { name: <config module ID>, 'idle-timeout': 60 }

environments

An array of environments (browsers) to test against. The same options used in capabilities can be provided for each environment specified in the array. To delete an option from the default capabilities, set its value to undefined.

If arrays are provided for browserName, version, platform, or platformVersion, all possible option permutations will be generated. For example:

environments: [
	{
		browserName: 'chrome',
		version: [ '23', '24' ],
		platform: [ 'Linux', 'Mac OS 10.8' ]
	}
]

This will generate 4 environments: Chrome 23 on Linux, Chrome 23 on Mac OS 10.8, Chrome 24 on Linux, and Chrome 24 on Mac OS 10.8. The other capabilities options specified for an environment are not permuted, but are simply used as-is.

Different cloud testing services use different capability values when specifying environment capabilities. For example, Sauce Labs uses 'Windows XP' to specify the Windows XP platform while BrowserStack uses 'XP'. Check the list above to find the right capabilities for your chosen platform.

Default: []

excludeInstrumentation

A regular expression that matches the path-part of URLs (starting from the end of proxyUrl, excluding any trailing slash) that should not be instrumented during testing. Use this to exclude dependencies from being reported in your code coverage results. (Intern code—that is, anything that loads from {{proxyUrl}}/__intern/—is always excluded from code coverage results.)

As an example, excludeInstrumentation: /^(?:tests|node_modules)\// would prevent any code in the tests and node_modules directories from being included in code coverage results.

Default: none

functionalSuites

An array of module IDs corresponding to individual functional test suites that you want to execute when running Intern. Functional tests are different from unit tests because they are executed on the local (Node.js) side, not the remote (browser) side, so are only available when using intern-runner.

Default: []

grep (2.1+)

A regular expression pattern that will be matched against full test IDs (parent suite ID + ' - ' + test name). Tests that do not match the pattern will be skipped during execution.

Default: /.*/

loader

Configuration options for the AMD module loader. Any AMD configuration options supported by the loader specified by useLoader can be used here. By default, the Dojo 2 loader is the AMD loader in use.

If you are testing an AMD application and need to use stub modules for testing, the map configuration option is the correct way to do this.

Default:

{
	baseUrl: baseUrl,
	packages: [
		{ name: 'intern', location: internDir }
	],
	map: {
		intern: {
			dojo: 'intern/node_modules/dojo',
			chai: 'intern/node_modules/chai/chai'
		},
		'*': {
			'intern/dojo': 'intern/node_modules/dojo'
		}
    }
}

The default baseUrl on Node.js is process.cwd(), and in the browser is internDir + '../../'.

maxConcurrency

The maximum number of environments that should be tested simultaneously. Set this to Infinity to test in all environments at once. You may want to reduce this if you have a limited number of test machines available, or are using a shared hosted account.

Default: 3

proxyPort

The port on which the code coverage instrumentation proxy will listen for requests.

Default: 9000

proxyUrl

The URL to the instrumentation proxy. You may decide to change this if you need to run the instrumentation proxy through another reverse proxy, or if your instrumentation proxy needs to be exposed on a public interface that your Selenium servers can access directly.

Default: http://localhost:9000/

reporters

An array of reporter names (for reporters in intern/lib/reporters) or complete module IDs (for custom reporters) corresponding to reporters that should be used to report test results.

Default: [ 'runner' ] (intern-runner) or [ 'console' ] (intern-client)

suites

An array of module IDs corresponding to individual unit test suites that you want to execute when running Intern. This option can be overridden in most cases by specifying one or more suites options on the command-line.

As of Intern 2.1, suites can also be set to null in order to skip loading the unit testing system when using intern-runner.

Default: []

tunnel (2.0+)

A Dig Dug tunnel name (for tunnels in Dig Dug) or complete module ID (for a custom tunnel) that should be used to tunnel WebDriver traffic to a remote WebDriver service (like BrowserStack or Sauce Labs).

Currently valid options are 'NullTunnel', 'BrowserStackTunnel', 'SauceLabsTunnel', and 'TestingBotTunnel'.

The 'NullTunnel' tunnel will create no tunnel, and is suitable for use with an existing Selenium server that does not need to be tunnelled (like a local Selenium installation).

Default: 'NullTunnel'

tunnelOptions (2.0+)

Additional options to pass to the WebDriver tunnel. Valid tunnel options for each type of tunnel can be found in the Dig Dug documentation.

Default: {}

useLoader

If you want to use an alternative AMD loader like RequireJS when running unit tests, provide the path to the alternative loader here, relative to the Intern directory. The host-node loader should be a Node.js module ID, and the host-browser loader should be a URL to a script file. The loader must support the baseUrl, map, and packages configuration options.

For example, to use RequireJS installed in your parent project:

useLoader: {
  'host-node': 'requirejs',
  'host-browser': '../../node_modules/requirejs/require.js'
}

Default:

{
  'host-node': 'dojo/dojo',
  'host-browser': 'node_modules/dojo/dojo.js'
}
Clone this wiki locally