Today, we’re very happy to announce the release of Intern 3.3! This is the result of several months of work to improve Intern and its Dig Dug and Leadfoot dependencies, as well as the introduction of a new intern-cli package to make command-line testing configuration even easier. sitecues by Ai Squared generously sponsored some of these efforts!
Releases
The two banner features in this release were version ranges and aliasing, and the SeleniumTunnel, as well as general improvement of Intern’s support for MS Edge (including a few fixes by Microsoft as the result of bugs filed during this process!).
SeleniumTunnel
SeleniumTunnel allows Intern to download, startup, and shutdown a local Selenium server. This gets rid of one of the main pain points with running local functional tests. This feature was implemented within the Dig Dug dependency.
To use it, Java must be installed and available within your system PATH. Set tunnel to ‘SeleniumTunnel’, and tunnelOptions.drivers to an array of the browsers that you’d like to test. The default is [ 'chrome' ]; the built in drivers are ‘chrome’, ‘firefox’, and ‘internet explorer’. These drivers should correspond to the browsers specified in the environments property.
{
// ...
tunnel: 'SeleniumTunnel',
tunnelOptions: {
drivers: [ 'internet explorer', 'chrome' ]
}
// ...
}Users may also provide an object in the driver’s list.
When SeleniumTunnel is started, it will download the selenium-standalone server JAR and the platform-specific WebDriver executables for the browsers specified in tunnelOptions.drivers. It will then start Selenium, providing any driver-specific options (like webdriver.chrome.driver). Selenium will be shut down when the tunnel’s stop method is called.
Note that to use SeleniumTunnel with Firefox 47+, two additional settings are required: marionette: true in the browser environment descriptor (to tell Selenium to use geckodriver), and excludeInstrumentation: true (to disable instrumentation since it currently breaks geckodriver). These settings are required whether or not SeleniumTunnel is being used to manage Selenium and geckodriver.
{
// ...
tunnel: 'SeleniumTunnel',
tunnelOptions: {
drivers: [ 'firefox' ]
},
excludeInstrumentation: true,
environments: [
{ browserName: 'firefox', marionette: true },
// ...
],
// ...
}Version ranges and aliases
Intern now allows ranges and aliases to be used when specifying browser versions. The only supported alias is ‘latest’, which refers to (surprise surprise) the latest browser version. Integer subtraction can also be used with ‘latest’, like ‘latest-1’, to get the next-to-latest version. Version ranges are two versions separated by ‘..’, like ’25..33′ or ’40..latest’. Both ranges and aliases will be resolved to arrays of versions by Intern at runtime.
The implementation of this feature is split between Intern and Dig Dug. Dig Dug’s Tunnel class now supports a getEnvironments method, which will return a list of the environments supported by the tunnel’s service (e.g., BrowserStack). When Intern sees a version range or alias in an environment specifier, it requests the available environments from the tunnel and then uses them to resolve the range or alias. Needless to say, this only works for services that provide lists of supported environments (the three supported cloud services currently support this feature).
Other updates
Leadfoot was updated to better support MS Edge, and it received other general improvements and bug fixes, but no new significant features were added in this release.
Intern’s handling of its AMD dependencies (chai, dojo, and diff) has changed. Since an AMD loader cannot search for dependencies like the Node.js loader, dependencies have to be placed in a known location. Originally, Intern linked those three packages from wherever Node.js put them into intern/node_modules. This started causing headaches when npm was updated to perform deduplication; npm would complain about extraneous packages if there were symlinks in intern/node_modules and actual packages in node_modules, and npm shrinkwrap would simply fail. The package links were moved to intern/browser_modules to get around this (so that npm wouldn’t pay attention to them anymore). That worked much of the time, but since npm performs deduplication any time npm install is run, the links in browser_modules could occasionally break if npm moved a linked package. The current release of Intern gets around this by simply copying the packages into intern/browser_modules at installation time. If npm install is run again at a later time, the install script will compare the package version being installed with the version in browser_modules and recopy the package if necessary.
Future work
We are currently working on a number of exciting features through a MOSS grant, and thinking through the best approach to make Intern easier for authoring tests as ES6 and TypeScript. If you are interested in contributing to Intern’s future features, please let us know!