jQuery Unit Testing With QUnit

I just found this library yesterday, and it’s fricken awesome, so I’m going to write a post about it

QUnit is an extension of jQuery that is designed for unit testing jQuery code. It’s really easy to setup and use, and allows you to unit test your jQuery / UI code for web applications. I’ve recently used it for the Display Config app we’re making for Interactive Retail, so I’ll give a few examples.

First off, you need to setup the environment. In other unit test scenarios this might involve making a separate test-only project, downloading a library, adding a few references, etc. For QUnit, it simply involves creating a webpage with certain items:

Pretty straightforward. We have a few references in our head element, and then mandatory elements to insert test results into (all the id=“qunit-*” parts). The best thing is, the test libraries are hosted for you, so you don’t really need to download or install anything to use it. Once you have this setup, it’s a matter of creating a test.js file for your unit tests.

Running that, you get results as follows:

And that’s it! Pretty epic win if you ask me. Now that we have this setup, I’ll give an example of a production-level unit test. But first, a little background on what we’re doing.

The Display Config web app is a asp.net app using the Service Reference / AJAX model similar to what we use in IntraiQ. The idea is the markup / UI is served immediately to the browser, and the actual data is retrieved async from a web service after the page has loaded, preventing long load times and the need to refresh the page to display or edit data. In the case of the main page for Display Config, we have two lists: a “source” list and a “stream” list. Source is a list of all products (phones for example) available to a dealer, where Stream is a list of items you want to display on the Surface / Touchscreen application. Both lists are populated after the page is loaded, meaning there’s a call to a web service to get the data.

Since we’re using asp.net, I’ve taken advantage of Master Pages to create our test site, which defines all the references and QUnit markup for us.

Thanks to this, for each test page we want to create, all we have to add is this:

Here’s what part of the production file, main.js, looks like.

MasterLibraryService is a service reference created by ASP.NET that basically wraps a web service and enables you to call the web service from javascript directly, without having to worry about serialization/deserialization of parameters or memorizing URLs. It’s defined as a public variable, so that we can redefine it in our unit test easily. For us to unit test this code properly, we need to segregate the web service reference from the code, since we don’t want to be calling the production service directly in our unit test. Thanks to javascript’s weakly-typed nature, we can do this really easily without using a mock framework like we do for C# code. This snipped is in my “main-tests.js” file.

So now that we’ve redefined the MasterLibraryService reference, we can write our unit test.

And running this in the browser (along with all my other tests for the main page) gives us this:

Easy as pie! As you can see above, I also have tests for checking to see if elements in the website have been inserted properly, meaning we can test the layout and functionality of UI components as well. And all this with jQuery syntax! Actually, it’s a pretty important part, so I’ll show just one more example of a layout unit test.

This post is getting pretty long, so I’ll end on a quote that was in one of the articles I linked to this week:

We won’t have unit tests for the sake of brevity, but in the real world, never refactor without unit tests. This is like doing a tightrope walk over a raging river whilst drunk. With no safety net. In the rain. With pirates. And a monkey is chewing on that rope. And it’s on fire. And everyone is shouting at you.