What’s next for Intern

By on May 7, 2014 9:21 am

Our first year of Intern has been a big one! It became a top trending project on GitHub for the month of our first release and has gained over 100 community forks and nearly 1700 stars so far. It’s in use today by tons of companies with names like Alfresco, Esri, IBM, Intuit, Mozilla, and Stripe. Because we believe so strongly in the power of testing, especially as Web applications continue to grow in size and complexity, we’re excited to continue our investment in Intern and its supporting technologies in order to provide the best possible testing experience for all Web developers.

Here’s a look at some of what’s coming to Intern this summer:

New WebDriver client

One of the few complaints that we receive from our users has been related to the complexity of debugging functional tests and extending the WebDriver client we originally selected for use with Intern, WD.js. While WD.js has been a great stepping stone, it doesn’t meet our high standards for code quality and robustness, and we’ve experienced bugs and breaking API changes when upgrading to new patch-versions that have made it impossible to receive bug fixes without causing unexpected changes to our users’ existing tests. As a result, we have been working over the past several weeks on a replacement client library we’re calling Leadfoot.

Leadfoot will be built into the next version of Intern and aims to provide an extremely robust, thoroughly tested, well-documented WebDriver client that follows common best practices in its design. It uses feature detection to work around known defects in WebDriver servers in order to ensure that no matter which server you’re testing against, as much functionality as possible has been corrected to operate to conform to specifications (and when the specifications are inconclusive, to conform to the behaviour of the majority of servers). Information about defects that cannot be automatically fixed and non-mandatory server features (like touch support) are exposed on the session’s capabilities object so you can avoid certain operations and tests in environments that will not be able to complete them successfully.

During the process of testing Leadfoot against Selenium servers in the wild, we’ve identified defects and inconsistencies in every single Selenium server and are reporting these issues on an ongoing basis in order to make Selenium testing better for everybody, not just Intern users. We’re also exploring the possibility of becoming more active in the development of the official WebDriver specification, though this may require additional community funding in order to ensure normal development can continue in parallel with very labour-intensive standards work. (Get in touch if you or your company would like to sponsor some of this work through the Dojo Foundation!)

Introducing Leadfoot will cause some functional testing APIs to change in order to accommodate a clearer, more idiomatic API that also reflects more closely portions of the draft WebDriver specification. In order to assist users in this transition, we will provide a compatibility shim that can be used to switch from the current WD.js API to the new API over time. Our hope is that, by completing this work all at once, this will be the one and only time that such a significant API change will need to occur.

Source map support

Another common problem when attempting to troubleshoot test failures is the fact that instrumentation for code coverage analysis changes line and column numbers by injecting additional code to the original JavaScript source. This means that stack traces from instrumented code don’t actually point to the correct locations in the code on disk. Code that is compiled from higher-level languages like TypeScript and CoffeeScript is also more frustrating to debug than it should be since the stack traces don’t point to the original lines of TypeScript/CoffeeScript code, even when instrumentation is disabled.

In order to address this issue, we’re currently working on new features, including patches to Istanbul, that enable Intern to read and process source maps recursively in order to provide stack traces that point to the correct line and column numbers of all original source code, even if it is compiled from another language, even if the code is running through the test runner on a browser that does not natively support source maps!

Reporter updates

One of the most common locally hosted CI services, Jenkins, includes plugins to display several different types of code coverage results that Intern provides after a build, but Intern doesn’t currently provide a JUnit XML reporter that integrates with the common Jenkins post-build task for displaying formatted test results. We’ll be correcting this soon and providing a JUnit-compatible XML reporter so test results can be viewed more easily within Jenkins, as well as other tools like SonarQube that support this output format.

We’re also going to be providing enhancements to the reporting system to provide for more robust configuration options for reporters, including better support for I/O redirection and code coverage warning levels.

Cucumber support

Companies that prefer to be able to have their non-coder business groups write test requirements will soon be able to do so using the standard Gherkin test description language, as Intern adds a fourth official test interface for Cucumber tests.

grep support

Currently, Intern allows test modules to be omitted from a run by overriding them on the command-line, but there is no way to quickly and easily isolate a single test for repeated execution without being forced to comment out code. A new grep feature, matching that found in other test frameworks, will allow you to skip tests whose IDs do not match the given regular expression. Portions of this work will also enable the addition of a feature that allows tests to be reported as skipped at runtime, so it is clearer that tests have been skipped rather than appearing to have completed successfully or appearing to not be registered.

Mock libraries

We’re still working through the best options for data mocking in the long-term. However, this summer, some new built-in mocking features should become available, including some code that makes it much easier to mock AMD dependencies when writing tests.

Internals cleanup

Unglamorous but necessary, additional cleanup within the internals of Intern will be occurring later this year. This work should not affect any public APIs, but will pave the way for some more advanced use cases and features, including augmenting the main lifecycle of the test runner and introducing additional middleware to the HTTP server that Intern normally creates so that server-side/Ajax testing is much easier to do.


We hope that these new features and enhancements will help our current users write tests more quickly than ever before, and give people that aren’t using Intern today many more good reasons to switch.

If you or your company have any specific enhancement requests not listed here, please make sure to file them in our issue tracker so we can put them on our timeline. If you have anything you’d like to see implemented more quickly, talk to us today about how you can commission us to add new features on an accelerated schedule.

You can also drop us a line if you’d like some free Intern stickers to help spread the love.

Have a great summer!

Comments

  • Len

    Is my observation correct: “cucumber support” is one of the things that never made it?

  • Yes, at this point, we started a branch as noted in https://github.com/theintern/intern/issues/81 , but we simply never got around to finishing it, as it wasn’t a top priority for our team. If someone wants to revisit that work and update the effort to make it work against Intern 3.0.x, we would review and land it, or if someone wants to sponsor the effort to finish it, we would be open to that as well.

  • With the work in progress cucumber branch being https://github.com/jason0x43/intern/tree/cucumber

  • Ronald Pijnacker

    Hi Dylan,
    I just restarted the work in https://github.com/rhpijnacker/intern.

  • Len

    I’m stumbling upon this page again. What about “mock libraries”?
    Sounds very useful to mock AMD dependencies, though I can’t find anything in the documentation.