QUnit let me set up unit tests and group them into modules. A module is just a simple way to organize related tests. (I’m not sure I’m using it as intended, but it’s working for me so far with the small set of tests I have thus far defined).
Between setting up good test cases and viewing coverage, we can reduce the risk that our code has hidden defects. Good times.
As you can see, I was using 1.13.0 at the time I wrote this blog post. Don’t forget to download and add the CSS file.
That out of the way, next step is to create some kind of test harness and reference the Qunit bits. I’m testing a bunch of functions in a script file called “QuizUtil.js” so I created an HTML page called “QuizUtil_test.html” as shown:
Here’s the code:
There are several things happening here:
- Referencing my code (QuizUtil.js)
- Referencing Qunity.js
- Defining some modules (getIDFromLookup, Cookies, and others)
- Placing a <div> whose ID is “qunit”.
Then, I just pull up this page and you get something like this:
If you look across the top, you have a few options, two of which are interesting:
- Hide passed tests: Pretty obvious. Can help your eye just see the problem areas and not a lot of clutter.
- Module: (drop down): This will filter the tests down to just those groups of tests you want.
As for the tests themselves – a few comments:
- It goes without saying that you need to write your code such that it’s testable in the first place. Using the tool can help enforce that discipline. For instance, I had a function called “getTodayAsCaml()”. This isn’t very testable since it takes no input argument and to test it for equality, we’d need to constantly update the test code to reflect the current date. I refactored it by adding a data input parameter then passing the current date when I want today’s date in CAML format.
- The Qunit framework documents its own tests and it seems pretty robust. It can do simple things like testing for equality and also has support for ajax style calls (both “real” or mocked using your favorite mocker).
- Going through the process also forces you to think through edge cases – what happens with “undefined” or null is passed into a function. It makes it dead simple to test these scenarios out. Good stuff.
Coverage with Blanket.js
Blanket.js complements Qunit by tracking the actual lines of code that execute during the course of running your tests. It integrates right into Qunit so even though it’s a whole separate app, it plays nicely – it really looks like it’s one seamless app.
This is blanket.js in action:
(You actually have to click on the “Enable coverage” checkbox at the top [see Figure 3] to enable this.)
The highlighted lines in Figure 5 have not been executed by any of my tests, so I need to devise a test that does cause them to execute if I want full coverage.
Get blanket.js working by following these steps:
- Download it from http://blanketjs.org/.
- Add it to your project
- Update your test harness page (QuizUtil_test.html in my case) as follows:
- Reference the code
- Decorate your <script> reference like this:
Blanket.js picks up the “data-cover” attribute and does its magic. It hooks into Qunit, updates the UI to add the “Enable coverage” option and voila!
Summary (TL; DR)
Use Qunit to write your test cases.
- Download it
- Add it to your project
- Write a test harness page
- Create your tests
- Refactor some of your code to be testable
- Be creative! Think of crazy, impossible scenarios and test them anyway.
Use blanket.js to ensure coverage
- Make sure Qunit is working
- Download blanket.js and add it to your project
- Add it to your test harness page:
- Add a reference to blanket.js
- Add a “data-cover” attribute to your <script> tag
- Run your Qunit tests.
I never did any of this before and had some rudimentary stuff working in a handful of hours.
Follow me on Twitter at http://www.twitter.com/pagalvin