We normally try to schedule new minor releases of Intern about once every four to six weeks, but when we are working on a major release, there will often be a larger than usual gap in the release cycle. In order to keep our users informed of what’s going on, we wanted to write about what we’ll be doing over the next six to twelve weeks for Intern 3, during which time there will be no new releases (except for possible critical patch releases).
Overhauling the testing lifecycle
Currently, the biggest blind spot for Intern’s self-tests is the code in client.js and runner.js that actually sets up the environment and kicks off testing. Because this code is fully procedural, we’re not able to run unit tests to verify that it works correctly without causing side-effects. The inability to easily extend from a common base type has also lead to some code duplication across the client & runner, and makes it more difficult than it should be to enable new execution mechanisms that users have requested (like a continuous reload mode).
As a result, one of the biggest changes in Intern 3 is to move all of this code into properly designed, reusable object types called executors. Making this change enables the core lifecycle mechanisms of Intern to be fully tested, which should reduce unfortunate release cycle churn as occurred with the Intern 2.2 release. It also lays the foundation for some exciting new execution modes in future minor releases, and improves early error detection and reporting.
Improving test reporting
One of our other goals for Intern for a while has been to add configurability to Intern’s test reporters. Luckily, overhauling the testing lifecycle has given us an excellent opportunity to also introduce a new reporter API and event hub that will enable fully configurable reporters, as well as support for safe asynchronous reporter operations. (For example, if you wanted to have a reporter save a screenshot of the browser before and after each test, this will be possible with the new reporter API.)
For this initial release, backwards-compatibility code will exist within Intern to support any current reporters that you’ve written. Also, not all built-in reporters may actually be upgraded to support the new API at once, due to time constraints. Because this work can be done in stages, this is a great opportunity for any potential new contributors to dig in and make a big impact on the next release!
Adios Geezer
As our tooling continues to improve and upstream libraries are modernised, supporting pre-ES5 environments becomes a greater drag on development and takes time away that we could be spending adding amazing new features to Intern. According to npm analytics, only about 7% of Intern downloaders use the Geezer edition, but it would take about 40% of our development time for this release cycle to continue to support this separate branch. The primary reason for the increase in development time is primarily due to the replacement of the obsolete dojo2-core dependency with the official Dojo 2 library, which includes some significant API changes to harmonise with the upcoming EcmaScript 6 specification. These changes are not backwards-compatible with the Dojo 1 library used by Geezer.
As a result of the above, our current plan is to end development on Geezer edition once Intern 3 is released, which means unit testing will no longer be supported in non-ES5 environments (IE8 and earlier). If you still need to support IE8 and earlier, Intern 2 will continue to be available, but with no new planned enhancements. Given the current browser landscape and feedback from some of our corporate users about their browser upgrade plans this year, we think that now is the right time to end support for these very outdated browsers.
However, if you anticipate still needing legacy browser support for unit testing in Intern 3 and might be interested in sponsoring development of a Geezer edition of Intern 3, please get in touch with us so we can coordinate and add this work to our project plan.
As time permits…
Additional minor improvements and enhancements to other parts of Intern will also be introduced in the upcoming release. We’ve already added code that allows the beforeEach and afterEach suite lifecycle methods to access the current test being executed, and we’ll be reviewing all open pull requests for any low-hanging fruit that can be integrated into the test system without conflicting with the other work that’s going into this release.
We’ve also recently added easy, medium, and hard difficulty labels to all Intern tickets where we’re looking for community contributions (Leadfoot tickets too!), so take a look and get involved if you use Intern and want to give something back!