JS Unit Testing with jQuery and Qunit

For those that like to do test-driven development, even in javascript, then you might be more than interested to learn about Qunit. Qunit is a test suite developed by the team at jQuery for their own use and which they have of course made available for others to use. And the great thing about it? All you need to get started is a JS and CSS file + a bit of HTML, of course!

Pre-existing JS Unit Tests

To get things kicked off the jQuery team provides access to a slew of their pre-existing tests, which can be downloaded and included as part of the range of your own tests, from AJAX, to dimensions, to events, to selector tests. You can find these tests are under the Reference Test Suites on the Qunit docs page of the jQuery website. They provide good fodder and resource for developing your own tests and ideas for them as well and are definitely worth a review for anyone just starting out in JS development and wanting to learn more about unit testing.

How to Set-up the Unit Tests

So what do you need to get started with jQuery Unit Testing? To begin with download both of the following files, Qunit.js, & Qunit.css, and include them in the head of your HTML document along with the latest version of jQuery. Then add the following HTML to the body of your document so that Qunit can render the test results properly:

     <h1 id="qunit-header">QUnit example</h1>
     <h2 id="qunit-banner"></h2>
     <h2 id="qunit-userAgent"></h2>
     <ol id="qunit-tests"></ol>

As you can see, getting set up with a basic testing environment is easy and pretty simple. With this set-up you can then include your own Qunit tests either in a SCRIPT tag or in your own JavaScript external include.

Writing Your Own Unit Tests

So now you’re ready to start writing your own tests, lets keep it clean and simple. The unit testing API is split into 3 sections:

1. Setup – The basics for defining tests, grouping them and getting them started.
2. Assertions – The Yay and the Nay of whether conditions have the met with boolean tests, comparison tests and recoursive comparison assertions for arrays, objects, etc.
3. Asynchronous Testing – Functions to stop and start the test runner.

Putting this together – not that we have looked in depth thus far – a very basic unit test would look as follows:

     module("Initial Test Module");

     test("Test with multiple assertions", function() {
       expect(2);
       equals( true, false, "failing test" );
       equals( true, true, "passing test" );
     });

Deconstructing the above test. “Module” provides a means by which to delineate individuals sets of unit tests. The “test” function with title and callback function params includes 2 further functions: “expect” and “equals”. The former sets the expectation for the number of assertions that have been defined and follow, whilst the latter obviously does the grunt work and returns the results. In defining an assertion you need to provide 3 things:

1. The expected result.
2. The result.
3. An error message.

As you can see writing even the most basic tests is super simple and pretty much a no-brainer. Adding complexity to the mix, with more test modules, multiple test and assertions interlinked and daisy chained together makes for a powerful brew.

Wrapping Things Up

To my mind there is little point in re-inventing the wheel, especially when so many good test examples exist, and which you can draw on for ideas in your own testing, but I thought it might be worth highlighting various points that can add flavour to your unit tests:

• “Module” provides lifecycle hooks for running code on setup and teardown of each test and you can just as easily bind tests to functions and events via jQuery also. Good examples exist in the actual jQuery core tests for the AJAX calls (core.js, ajax.js, etcetera).
• Daising chaining your assertions together makes for useful testing when wishing to assert that different types of scenarios, for example when making invalid requests to an AJAX web service with illegal characters, insufficient parameters, unauthorised params etc will fail properly, and thus pass your tests accordingly.  Definitely worth using when testing forms and data entry.
• Manipulate the DOM and everything else has much as possible during the course of your tests.  Alter the underlying code and test for the results as you go.  You shouldn’t be afraid to try and break things and test against them. It’s very easy to get into the developer mindset where you know how they should work, and you are can make them work perfectly all the time.

So there you have it.  Hopefully more than ready to go out and unit test your way to heaven, or at least your dev team lead’s heart.  If he or she even has one.  We know what vamp-like figures rule that roost … hahaha!

Related Posts

• Testing Website Slow Performance