Intern is complete JavaScript test stack, with support for the entire testing lifecycle. Intern 4 keeps many of the internals of Intern 3, but updates the external interface and usage model to better fit into modern workflows.

Why Intern

Intern’s goal is to simplify the process of writing complete, high quality application test suites. Some of the key benefits of Intern include:

  • Support for both unit and functional tests
  • Built-in assertions (via Chai)
  • Built-in code coverage (via Istanbul)
  • A thoroughly typed API for TypeScript users
  • Support for external loaders (Dojo, SystemJS, etc.) in Node and browser environments
  • Multiple test writing interfaces (BDD, TDD, object)

Unlike many other JavaScript testing tools, Intern supports both unit and functional testing out-of-the-box, and it doesn’t require a large number of plugins to be productive. Intern also doesn’t focus on any particular framework, and it’s not strongly opinionated about how tests are written or where they’re located.

Intern 4 was designed to handle projects of all sizes. It has full support for TypeScript, which can prevent a range of errors through static type checking. It has built-in support for several cloud testing services, allowing unit and functional tests to be run on a huge number of OS + browser combinations. Intern also includes code-coverage functionality, allowing it to show which application files are being exercised by tests, and how thoroughly they are covered. Code coverage can be tracked through transpilation, and even when bundling is used.

For a more complete list of features supported by Intern, and to see how it compares to some other popular testing tools, check out the feature list on the Intern site.

What’s New

While the overall user experience for Intern should feel familiar, users of previous Intern versions will immediately notice some differences in version 4. First off, Intern is no longer based on AMD. While Intern 4 can still load suites and application modules that use AMD, it no longer depends on this format. Instead, Intern uses the native module or script loading mechanism. In Node, this is require. In browsers, most of which don’t have a built-in loader, Intern is loaded as a monolithic bundle, and it uses script injection to load test suites and plugin scripts. All of this together means that suites no longer have to be written as AMD modules, and in fact don’t have to be written as modules at all.

Another change is with how Intern is configured. Previous versions of Intern were configured with an AMD module that resolved to or returned an object of configuration data. While this style of configuration is flexible, it can quickly grow complex, and can make passing configuration information between Node and the browser difficult. Instead, Intern 4 is configured with a declarative JSON object. To make configuration easy, config files can inherit from each other, and properties will often accept shorthand values (e.g., "environments": "chrome" will work in place of "environments": [{"browserName": "chrome"}]).

Executing Intern has gotten simpler. Previous versions of Intern had three runner scripts: intern-client and intern-runner were Node scripts used to run unit and functional tests in Node, and client.html was used to run unit tests in a browser. Standard Node and browser run commands looked like:

$ ./node_modules/.bin/intern-client config=tests/intern
$ ./node_modules/.bin/intern-runner config=tests/intern
__intern/client.html?config=tests/intern

Intern 4 has two runner scripts: intern for running unit and functional tests in Node, and index.html for running unit tests in the browser. Both scripts assume a default location for the config file, and using index.html for the browser client means a user generally won’t need to explicitly type it out. Standard run commands now look like:

$ ./node_modules/.bin/intern
__intern/

Learn More

Of course, there’s a lot more to Intern than we’ve mentioned here. If you’d like to learn more, check out Intern’s official documentation and the Intern tutorial. Existing users may be particularly interested in the page on changes from Intern 3 to 4.

We encourage community contributions — if you notice a mistake in the docs, or have a suggestion for something that could be covered better, let us know!