Getting started with Intern 4

Unless you have a time machine or a TARDIS, it’s pretty rare to have solid documentation in place before an open source project is released! While we’re getting close to a beta release with the Intern 4 and while we still have a fair amount of documentation and refinements to complete, a number of people have started using Intern 4 to leverage its support for easier testing with modern ES6+ and/or TypeScript features.

Benefits of Intern 4

Intern 4 has many benefits and improvements over Intern 3 and previous approaches to testing. A few of these changes in approach are things that are now possible because of the modern JavaScript ecosystem.

No loader configuration

One of the biggest challenges for users getting started with Intern in the past was configuring Intern’s module loader. With Intern 4, we simply assume that you bring your own module loader or bundler, if needed.. Rather than requiring projects to adapt to Intern’s AMD environment, Intern 4 will adapt to the user’s environment.

The result is that Intern and its packages will be loaded like any other module, and Intern can be built/optimized for a target environment and/or loader. We believe this will make it simpler for users and developers to understand and use.

If you’re just testing Node.js code, or non-modular browser code, you do not have to specify any loader.

When testing code or writing test code that requires an external loader, within your Intern configuration, you now simply specify a loader property which can be a string with a loader name or the path to a loader script. It may also be an object with script and options properties. Intern provides built-in loader scripts for Dojo, Dojo 2, and SystemJS, accessible through the aliases dojo, dojo2, and systemjs, and it is straightforward to run tests using webpack and other bundlers. Environments with native ESM loader support will also be an option in the near future.

Consistent test runner

With Intern 3 and earlier, we had different client vs. runner commands to run a test suite. With Intern 4, we have a single unified test script. Instead you specify if a test suite is a unit test suite (suites), functional test suite functionalSuites, etc. The method used to run tests (in Node.js, in remote browsers, or as functional tests) is now entirely defined by the configuration rather than by how the tests are run (intern-client vs intern-runner). This should help our users have less challenges when getting started with Intern 4.

Extension points

With Intern 4, we now have more clearly defined extension points. In Intern 3 there were a variety of ways to extend Intern — the configuration file, config.before and config.after hooks, and custom reporters. In Intern 4, there is really just one way — event listeners in plugins. Plugins are scripts that are loaded by Intern just before test suites. They can access the Intern config, add event listeners, and register values (data or functionality) that can be used in test suites. All of Interns extensions (interfaces, reporters, assertions) are registered and made available through the plugin system.

Programmatic interface

Another new feature is that Intern has a more well defined programmatic interface. It is now possible to instantiate and configure an Intern executor in a user script!