Skip to content

Running Intern

Jump to bottom
Colin Snover edited this page Feb 28, 2014 · 18 revisions

The following arguments can be used when running Intern:

Argument Optional? Description Environment
autoRun Yes When set to false, tests will not start running automatically after they are all loaded. Otherwise, if true or left undefined, tests will start running automatically. browser, client cli
config No The module ID of the configuration file that should be used when running Intern. The module ID will be resolved relative to the current working directory on the command-line, and relative to the baseUrl option in the browser. browser, cli
proxyOnly Yes When using runner.js, the proxyOnly argument may be provided. This causes the runner to start the instrumenting proxy but perform no other work, so you can load instrumented tests by manually navigating to {{proxyUrl}}/__intern/client.html. runner cli
reporters Yes One or more reporters that should be used in lieu of the reporters listed in the configuration file. To specify multiple reporters, simply provide the reporters argument multiple times. browser, cli
suites Yes One or more module IDs that should be tested in lieu of the full list of suites in the configuration file. To specify multiple suites, simply provide the suites argument multiple times. browser, cli

More detailed argument usage examples can be found below.

There are several different ways to actually use Intern, depending upon your needs:

As a stand-alone browser client

This execution method is useful when you are in the process of writing unit tests that require a browser and you need to quickly check to make sure that they are actually working. It is invoked by navigating directly to client.html. The config argument should be the module ID of your project’s Intern configuration file (typically tests/intern). One or more suites and reporters arguments may also be used. A typical execution that runs all tests and outputs results to the Web console would look like this:

http://localhost/my-project/node_modules/intern/client.html?config=tests/intern

A more complex execution might look like this:

http://localhost/my-project/node_modules/intern/client.html?config=tests/intern&suites=my-package/tests/request
&suites=my-package/tests/animation&reporters=console&reporters=html

As a stand-alone Node.js client

This execution method is useful when you are in the process of writing unit tests that do not require a browser and you want to quickly check to make sure that they are actually working. It is invoked by running intern-client. The command-line arguments for client.js are identical to the URL arguments for running a stand-alone browser client. A typical execution that runs all tests and outputs results to the console would look like this:

intern-client config=tests/intern

A more complex execution might look like this:

intern-client config=tests/intern suites=my-package/tests/request \
  suites=my-package/tests/animation reporters=console reporters=lcov

Note that when running on Windows, all command-line options must be surrounded by quotes. Also note that the commands above rely on npm being installed and configured properly; if you do not have your environment PATH set properly, you may run my-package/node_modules/intern/bin/intern-client.js directly instead.

As an instrumenting proxy for generating code coverage data

This execution method is useful when you want to generate raw code coverage data for use with Istanbul without needing to set up a browser testing infrastructure. It is invoked by running intern-runner proxyOnly. The config argument should be the module ID of your project’s Intern configuration file (typically tests/intern). The proxy will run indefinitely until you quit using Ctrl+C. An execution of this method would look like this:

intern-runner config=tests/intern proxyOnly

Note that because this method does not run any tests, the suites and reporters options are not applicable. Also note that the commands above rely on npm being installed and configured properly; if you do not have your environment PATH set properly, you may run my-package/node_modules/intern/bin/intern-runner.js directly instead.

As a test runner for multi-platform testing

This execution method is useful when you want to run tests across all supported environments without needing a separate continuous integration server. It is invoked by running intern-runner without the proxyOnly argument. One or more reporters arguments may also be added to override the reporters specified in the config.

In order to use this method, you will need one of the following:

  • A Sauce Labs account, if you do not want to self-manage your testing infrastructure
  • A Selenium 2 Server, if you only need to run tests on one platform
  • A Selenium 2 Grid, if you need to run tests across multiple platforms

This execution method is required for functional testing, as a server is required in order to drive the client browser.

More information on how to configure Intern to work with your testing infrastructure can be found on the Configuring Intern page.

A typical execution of this method would look like this:

intern-runner config=tests/intern

A more complex execution would look like this:

intern-runner config=tests/intern reporters=runner reporters=lcov

As a test runner for continuous integration

This execution method useful when you want to enforce code quality standards across an entire project and ensure that any broken code committed to your canonical project repository is reported immediately.

In order to use this method, in addition to the above, you will need one of the following:

  • A Travis CI account and a GitHub repository
  • A custom post-receive (Git) or post-commit (Subversion) hook that executes intern-runner as described above and notifies you if it returns a non-zero exit code.

You may also use other third party continuous integration solutions like Jenkins CI or TeamCity. We are very interested in providing wider support for these solutions, so please submit a pull request if you have created any plugins that enable easy interoperability.

An execution of this method would use the same command-line arguments from the previous section, except the command is executed by your post-commit script or CI software instead.

More information on integration with Travis CI can be found on the Travis CI Integration page.

Clone this wiki locally