QUnit 1.16 Release and Roadmap

Posted on by

We’ve just released QUnit 1.16, an important milestone for the project. This release introduces several new APIs that will become the default in QUnit 2.0. To help migrate to these APIs, you can start using them today in 1.16. Our 2.x upgrade guide provides all the details you need to change your existing test suite to the new APIs.

Here’s a quick overview of the new APIs:

QUnit.test( "assert.async() test", function( assert ) {
  var done = assert.async();
  var input = $( "#test-input" ).focus();
  setTimeout(function() {
    assert.equal( document.activeElement, input[0], "Input was focused" );
    done();
  });
});

You still define tests by calling QUnit.test and passing a name and a callback. The callback receives a assert argument that contains all assertion methods. The assert.async() method is brand new, replacing the old stop() method. The returned callback, here named done is later called when the test is finished, replacing the old start() method.

In addition, QUnit 1.16 contains several improvements and new features:

  • Promise support: As an enhancement for the async control, test blocks are now Promise aware, meaning QUnit will wait for the test to resolve with the pass or fail statement.
  • QUnit asynchronous tests can also now be defined using the new var done = assert.async() method instead of the old stop()/start(), making them specific to the test block.
  • QUnit.skip: This method can be used to define tests that aren’t executed, as placeholders or to temporarily disable an existing test (instead of commenting it out). The skipped test is still displayed in the HTML reporter, marked prominently as “SKIPPED”.
  • testId URL parameter: When clicking the “Rerun” link for a single test, a hash of the test name is now used to reference the test, called testId, instead of the previous testNumber. Using a hash makes sure that the order of tests can change, and QUnit will still rerun the same test you’ve selected before.
  • CommonJS exports: QUnit now also looks for a exports object and uses that to export itself, making QUnit usable on Rhino with the -require option.
  • There are a few more minor changes. For a full list, check out the changelog.

Roadmap

For future releases, we have several improvements planned as well:

Standardized reporter interface

Currently integration of any unit testing library into other tools like PhantomJS or browserstack-runner or Karma requires custom integration code, a combination of library and tools. We’ve started an effort to create a standard reporter interface that all testing libraries could implement, called js-reporters, to be consumed by those tools. Coordinating between the various projects and getting them to agree on and implement a common API takes time, but will yield better testing infrastructure for everyone.

Better diff output

When writing unit tests that compare objects with deep structures or many properties, like Ember models or Moment instances, the current diff output is slow and inefficient. There are also comparisons where the diff is hard to read. Replacing the diff library and implementing custom optimizations, like only showing diffs for leafs in big objects, will make QUnit’s HTML reporter even more developer friendly. We have a list of all diff-related issues.

Better support for writing custom assertions

Custom assertions are a powerful method of abstraction in test suites. They are currently underused. We want to investigate better APIs for writing custom assertions, along with better documentation of existing and new APIs.

Support for nested modules

Nesting modules, like Jasmine and Mocha support it, gives more flexibility in structuring test suites. There is existing discussion and prototypes, but no consensus on the API, yet.

For any breaking changes, we’ll apply the same migration model that we’re currently using. All backwards compatible changes will make it into the next minor release, any incompatible changes will be introduced with a migration layer in a minor release, removing the migration layer in the next major release.

The QUnit Team

The QUnit team also would like to use this opportunity to introduce itself:

At the jQuery Conference in Chicago, September 2014, from left to right: Jörn Zaefferer, Timo “Krinkle” Tijhof, James M. Greene, and Leonardo Balter

 

QUnit 1.11 Release: A Look Back (and Forth)

Posted on by

Earlier this week, we released a new version of QUnit, jQuery’s solution for unit testing JavaScript. Along with some details on the new release, I wanted to take this opportunity to tell you a bit more about QUnit, where it came from and where it is going. I’m also looking for your input, to help us shape the future of JavaScript testing.

New in 1.11

The most visible change (aside from our new purple logo) is a runtime display for individual tests. Before, QUnit would show you how long it took to run a full test suite. Now it’ll also show individual times for each test, making it easy to spot slow tests in your test suite. Since it’s useful to have unit tests finish within seconds, tuning tests now becomes a bit easier.

Other changes are mostly bug fixes to built-in features, and various improvements to add-ons. There’s a new theme, a overhaul of the PhantomJS add-on to use its callback system and more. Check out the changelog for a full list of changes.

QUnit’s Evolution

Unlike jQuery UI and jQuery Mobile, QUnit doesn’t have a code dependency on jQuery, it just happens to be developed as a jQuery Foundation project. How did that happen? It all started a long time ago, but in a galaxy pretty close by. Back in 2006, this guy named John was working on jQuery and wrote his own little unit test runner, since there wasn’t much to start with. Two years later, John and I figured that this test runner would be useful as a standalone tool, and it got the name QUnit, as a mashup of jQuery and JUnit. It lived in the same SVN repository as jQuery itself, along with a few pages on the jQuery wiki.

In 2009, we moved it to its own GitHub repository and rewrote QUnit to get rid of the dependency on jQuery. Until October 2011, QUnit was just updated in master, without versioned releases, which kind of worked, but also caused maintenance and dependency headaches. I finally tagged 1.0.0, along with regular releases since then. Recently, QUnit got its own website and API reference.

Moving Forward

Today QUnit is used not only to test jQuery Core, jQuery UI and jQuery Mobile, but many other other projects as well. One notable example is Ember.js. Those guys don’t get tired of telling me how great QUnit is, putting emphasis on the reliability. We’d like to find out more about how developers are using QUnit, so if you’re using QUnit (or planning to), please take a few minutes to complete this brief survey.

From the ~50 answers we’ve received so far, it’s clear that people use QUnit since it’s so easy to get started with, and we certainly intend to keep it that way. It’s also clear that a lot of people are looking for tools and guides on integrating QUnit in CI tools like Jenkins, which is also something we’re planning to work on. Along with that comes a heavy refactoring of the QUnit codebase, which currently lives in a single JS file (and a sister CSS file). We’re going to split the codebase into a few modules, which should help future maintenance and make it easier to integrate other libraries. This will allow us to improve our diff implementation, for instance.

If you’re interested in following future QUnit updates, follow @qunitjs on Twitter and watch the project on GitHub.

About client-side form validation and frameworks

Posted on by

There is a good article about client-side form validation on the Interaction Design Blog. It describes important points to keep in mind when building your own framework for client-side validation.

Of course the alternative to building your own framework is to use an existing one. This approach yields some important advantages, amonst them the “given enough eyeballs, all bugs are shallow” principle.

Lets see how well the validation plugin currently performs on the points listed in the article:

1. Use a form validation framework or a form validation library

Check.

2. Focus on solving the big validation problems

As soon as you start developing and implementing your validation, it is easy trying to address all potential validation that is needed for all types of input. My advice is to try to catch 75-85% of the potential user input errors in the front-end validation. Trying to catch all will lead to the following:

  • Bloated code, your framework will grow too large
  • More or less impossible to test client side validation as there are too many combinations of validation that can go wrong
  • Business rules will move to the front-end.(More on how to avoid this by using Ajax later)

Well, bloated code is a problem I tried to address with lots of refactoring. The current codebase has 1446 lines (about half of it being inline documentation). A few weeks ago Dan G. Switzer took a look at the plugin and was able to provide excellent help on specific code-related problems within a few hours.

About testing: The current testsuite for the validation plugin runs 65 tests with over 350 assertions. jQuery’s testsuite runs about 500 assertions. I seems to have a good code coverage, as I added tests for all occuring issues whenever possible. Regression issues are quite likely to be catched by the testsuite, as well as it helps a lot while developing.

Testing against browser events and with AJAX is still a very difficult task, even with the AJAX support in jQuery’s testsuite.

About business rules moving to the front end: Thats more of a design and architectural problem. Avoiding that using AJAX gets supported with the upcoming 1.2 release.

3. Do Form Validation before form is submitted

The message here is to validate when the user inputs something, instead of waiting for the submit event. Pre 1.0 versions allowed you to specify a single event to check individual elements, eg. blur or keyup. That worked in some cases, and was disturbing in other cases, where the user clicked on an input and was welcomed with an annyoing error message. To address those issues, a more sophisticated system was released in 1.1. Basically the plugin waits with validation until the user blurs a field where he entered something incomplete. If the field is already marked invalid (eg. after an attempt to submit an invalid form), all elements are validated on keyup (textinputs) or click (checkbox, radio). The current implementation isn’t perfect yet, and of course feedback is appreciated.

4. Use Ajax Form Validation for business data input

A small teaser for the AJAX validation in 1.2:

$("#myform").validate({
  rules: {
    username: {
      required: true,
      minLength: 2,
      remote: "users.php"
    }
  },
  messages: {
    username: {
      required: "Enter your username",
      minLength: "At least 2 characters are necessary",
      remote: String.format("The name {0} is already in use")
    }
  }
});

The API allows you to use the same declarative style for remote validation as you are used to use for local validation. String.format creates another function that is later called with the value the user entered, resulting in something like “The name asdf is already in use” as the error message.

Check the AJAX validation preview for more details.

5. Do extensive testing of your javascript form validation

That is covered above.

6. Rewrite input data to valid formats

Now this is an interesting point. Basically the idea is to accept “20070515” as a valid date, transforming it into “2007-05-15” for validation. I haven’t seen any specific requests for a feature like this, so if anyone is interested, let me know. Meanwhile a good idea may be to use the masked input plugin to help and assist the user typing the correct format.

7. Attach javascript form validation late in the design process

That is a very good recommendation. jQuery helps a lot with this, due to its unobtrusive nature. Design your form without any JavaScript at all, and add it later, improving the user experience (UX) as much as possible.

8. Make the script i18n- and l10n-compatible

In other words: Avoid hard-coded strings, instead make it as easy as possible to replace them with the current locale.

The validation plugin allows you to translate all default messages by just overwriting them. Its easy to include a file after the plugin file that contains something like the following:

$.extend($.validator.messages, {
  required: "Eingabe nötig",
  email: "Bitte eine gültige E-Mail-Adresse eingeben",
  ...
});

That approach works quite well. You can gather other translation in the same file, for example labels for the datepicker.

To include the proper right translation file for the user’s locale is then a mere serverside issue.

Other problems, eg. different number or date formats, can be covered by writing custom methods, or overwriting the default ones (in $.validator.methods). Methods for german date and number formats are provided by default: date (default JavaScript Date format), dateISO (1990-01-01 or 1990/01/01), dateDE (01.01.1990 or 2.12.2012) and number (100,000.59) and numberDE (100.000,59) are available. Though currently none of those validates any ranges, eg. 0001-13-50 is also a valid iso date.

9. Add callback functions to validator framework

The most important callback function the validation plugin provides is the submitHandler. It is called when a valid form is submitted, allowing you to eg. submit the form via AJAX. Others are available like errorPlacement, to customize where error messages are inserted into the DOM, eg. for table layouts.

In 1.2 a callback for invalid forms gets added, called each time the user submits a form and it is invalid. So far the showErrors callback could be used for that, but that one gets also called each time is single element is validated. The new callback can then be used to update a message like “There are 6 issues in the form below”. Showing and hiding such a message can be handled using the existing errorContainer options.

10. Make your framework/library extensible

The most important point to extend the validation plugin with your own stuff is $.validator.addMethod. It allows you to add any validation method you need. By keeping your own custom methods inside your own files it is easy to update the plugin itself.

Its quite likely that the first approach to AJAX validation will evolve into $.validator.addRemoteMethod, providing all the necessary boilerplate code for remote AJAX methods, but allowing you use any required protocol. It won’t matter if you use get or post, send a single value or the whole form to the server, and if the server returns only true or false, or an error message to display, in whatever format you prefer or need to work with. Of course it would require a bit more work to implement the method, but provides a great flexibility. Your feedback on this is essential, as I avoid to randomly guess what you may need.

I hope this gives a good idea about the current status of the form validation and its progress and should help with the descision to use it or not.