The motivation for Intern 4 is to make it easier to author tests with ES6+ features within tests, with or without transpilation.
Want to skim? Here’s the Intern Roadmap which lists our high level status for each Intern release going forward.
Or if you’re curious to know the details for our plans for Intern this year, read on:
Intern already has a wide array of capabilities and today we’re pleased to announce one more: accessibility testing. Thanks to a generous grant from Mozilla Open Source Support we’ve created the intern-a11y plugin, which allows users to run accessibility tests on pages or components using Intern.
Today we’re pleased to announce the release of Intern 3.4. This release brings usability enhancements and bugfixes, including a new benchmarking mode! We’ve outlined some of the features below, but as always, visit the release notes for more details.
A number of contributors made this release possible. Thanks to all of them for their code and issue submissions. We’d especially like to thank Mozilla Open Source Support for their sponsorship of the performance benchmarking functionality.
With Intern you can easily run tests using your local machine’s web browser or on any other machine running a Selenium server. Sometimes a project will need to be tested across a wide range of platforms and browsers, more than an individual user or even an enterprise may have available. Cloud testing services such as BrowserStack, CrossBrowserTesting, Sauce Labs, and TestingBot provide access to hundreds of VMs running various combinations of platform and browser versions. Intern has out-of-the-box support for several such services.
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!
One of Intern’s goals has always been to make writing high-quality tests easier, but running those tests hasn’t always been straightforward. Now there‘s a new way to run Intern tests — intern-cli. This package provides an
intern command that has a POSIX-like interface, using familiar flags and options like
--help. It follows some conventions that make running Intern simpler, and provides plenty of inline help. It even makes getting started with Intern easier with a new
Intern, via the Leadfoot WebDriver library, provides a lot of low-level control over the browsers it uses to run tests. Tests can navigate to new pages, resize the browser window, examine elements on a page, and interact with controls like inputs and buttons. Unfortunately, with all this power can come great complexity. Many testing tasks will involve a large number of low-level operations and dealing with these can be error prone and make tests difficult to follow. Command helpers to the rescue!
Today we’re pleased to announce the release of Intern 2.2. Along with improvements to existing functionality and a few bug fixes, this release includes a new console-mode reporter that provides a more detailed view of the testing process and improved rendering of differences between objects. Full details are in the release notes; read on for some of the highlights!
Today we’re happy to announce the release of Intern 2.1. This release contains several bugfixes and improvements to existing functionality, as well as new features to make running tests and handling test results easier. The full list of enhancements and bugfixes is available in the release notes. Here are some of the highlights!
More output options
Two new reporters have been added to Intern: an HTML reporter for the browser client and a JUnit XML reporter.
The HTML reporter is a new default reporter for Intern’s browser client runner (
client.html). It displays at the end of a test run, summarizing the test results and presenting them in an easy-to-read format:
The output of the JUnit reporter, on the other hand, is meant for machine consumption. It aggregates test results and outputs them in a
report.xml file that follows generally accepted standards for JUnit-compatible XML. This makes it much easier to plug Intern into tools that accept JUnit reports, like Jenkins.
A common practice when adding new elements to a document is to add them to a container DIV and then insert that node into into a document. A lesser used alternative is the
DocumentFragment class. So, what is a document fragment, and when should you use one instead of a container DIV?