in JavaScript

Javascript Unit testning with QUnit

Share on Facebook0Tweet about this on TwitterShare on LinkedIn0Share on Google+0Email this to someone

We have just started a really cool project at work. And it didn’t take long until my team realized that we are using JavaScript a lot, and are dependence that the JavaScript are doing just what we want.

There are a lot of cases where we do complicated calculations, and relay on other properties in other classes/objects.
So when we realized that this was the case, we sat down and started to brainstorm, what can we do to ensure that the code we write won’t fail?

What do we do usually (C#, asp.net)? We write Unit tests. So how do we do this in JavaScript?

It didn’t take long time reading around to understand that QUnit is one of the popular Unit testing frameworks out there for JavaScript. QUnit was originally developed by John Resig and was in the start dependent on jQuery but a rewrite fixed this, and is now a standalone library (quite nice). QUnit is simple to use and easy to begin with.

QUnit’s built in assert list is the following:

  • ok(state)
  • equal(actual, expected)
  • notEqual(actual, expected)
  • deepEqual(actual, expected)
  • notDeepEqual(actual, expected)
  • strictEqual(actual, expected)
  • notStrictEqual(actual, expected)
  • raises(block)

There is one more parameter that is optional and that is the message (string) parameter. Plain text that will be display with the test result.
There are some differences comparing to other testing frameworks, if you for example are used to write unit test with NUnit you may already notice that the arguments in the assert methods are swapped, in NUnit the expected parameter comes first and the actual parameter comes second.
This might make everything a bit strange in the start but it doesn’t take long until you have grabbed the concept and are writing tests like you usually do.
There is a big difference between JavaScript and other languages and that is the ”equal” comparison. JavaScript is both strict and type-converting. This means, we don’t always check the type, only the value when we compare, and sometimes we check both the value and the type. This with the == and the ===.
The three equals (===) is checking both type and value, and the two equal (==) is checking the value. With this in mind, the following examples will make perfect sense:

So, let’s get back to QUnit. With the operators that we got in JavaScript, that we just went through above, we can almost see on the assert names what method is using which comparison.
The first ”ok(state)”, will take a state (a Boolean expression) as parameter and tell if the test passed or failed, ex:

The test scenarios for the rest assert methods is as below

equal ==
notEqual !=
strictEqual ===
notStrictEqual !==

These methods above are good to use at almost any variables. But if you are going to compare objects, and arrays you want to use the: deepEqual and the notDeepEqual.
The deepEqual method, makes a deep recursive comparison, and makes a strict check (===, on type and value).
The notDeepEqual makes an inverted result from deepEqual (!==, on type and value).
Before we start to lab with QUnit, we need to know one more thing. It will all start with a test function, which will run the test. This function looks like this:

Now when we know what each assertion does, and we know how a test function looks like, let’s try QUnit with some code.
First thing we need to do is to grab some HTML that will help us display the result of the test we are writing.

Now when we got the HTML, with the QUnit css, and the QUnit framework in our HTML file. Let’s save it: QunitTests.html, and open it in a browser.
You should see a result something like this (depends a little on your browser, you will see your user agent, I’m using chrome as you can see below):

Qunit Default

Now let’s add a simple test inside our script tags:

And if you reload your page, you will see that the test was run, and it passed.
Pretty simple yeah? Now if you would change your (true == true), to (true == false) and reload your page again, you will see that the test didn’t passed and it will be marked red, you will also see the source to the test, and the test message (if you choose to fill one in, or else you will see ”failed” as message).
If you have a test that passed, you can click on it and the test message will be displayed right below your test (if you choose to fill a message in, or else you will see ”okay”).
Now when we have seen a test pass, and a test fail. Let’s try out the other methods QUnit gives us, i ended up with a file like this:

Simple, clean and easy to use in my opinion.
Now what if I got a lot of tests and want to organize your tests, like ”TextFixures”. Yes you can do this!
QUnit has modules that helps you do this, and it is simple to use, just add ”module(”name on the module”) before the tests you would like in your module. You don’t need to wrap your test inside the module, it will just take all the tests that comes after until a new ”module” will come. When that happens, it will ”break” and organize the new tests that comes after the second module to that one. Let’s add 2 modules to our tests:

You now see the module name before your test name, and you will see what test belong to what module.
The module dosen’t only make it possible to organize your tests, it also has functionality for a ”setup” function and a ”teardown” function. That will be runned before each test inside the module (the setup function) and after each test inside the function (the teardown function) ex:

What is your point of view on testing JavaScript, do you unit test your JavaScript code?! Have you tried another Unit testing framework for JavaScript that you think is better, please leave a comment with your thoughts. All knowledge is good knowledge.

Share on Facebook0Tweet about this on TwitterShare on LinkedIn0Share on Google+0Email this to someone

Write a Comment

Comment