Your quick guide to better JavaScript testing

Try using Karma, Jasmine, and Istanbul for your JavaScript testing workflow

Let me say this as simply as possible: You need to test your JavaScript code. Yes, I understand how easy it is to drag your feet when you don't know about the tools that make testing quick and painless for you. That's why I'm here to help.

In my early days of testing, my biggest hangup was the drudgery of configuring and running tests. The "test runner" was at the center of the pain: It consisted of an HTML page that included the test framework, all of my JavaScript files, and all of my test files. To run my tests, I needed to open the page in a browser and run it to see the results. When a test failed, I'd fix some code, return to the browser, and refresh -- or rather, test across multiple browsers and refresh them all, watching each individually for results. To make matters worse, to add a new source file or test, I'd have to manually modify the test runner page to include the new files.

Now test a serious JavaScript project and watch your workload grow. Yeah, you're testing, but it's painful.

There must be some great tools to make this easier, right? Of course there are -- but as with anything else JavaScript these days, there are a million of 'em. Here are my favorites and how I use them. For a more in-depth treatment, check out this page, where I've written a walkthrough using these tools to test a basic single-page Web app running Backbone.js.

Getting started with Karma
Karma is now the cornerstone of my testing workflow. Karma, formerly (for obvious reasons) Testacular, is a fantastic automated test runner that keeps my tests running and my sanity intact. Maintained by an Angular.js team member at Google, Karma provides great functionality out of the box and is easily extendable.

Here's what it looks like to run tests: Run karma start from the root directory of your JavaScript project. That's it. That command will automatically launch all the browsers you specified in the config file and run the tests. Then it will watch your file system for changes and rerun your tests in every browser as you save.

The catch is that you have to prepare a configuration file to set up the tests you want. The file is pretty straightforward: Run karma init and it'll walk you through all the basics and generate a file based on your needs. First, you must decide what test framework you will use.

Karma itself is test-framework agnostic and relies on plug-ins to know how to deal with frameworks. Plug-ins are available for most of the frameworks you'll want to use, including Jasmine, Mocha, and QUnit. If you're not using one of those, check Npm (the official package manager for Node.js) for a Karma plug-in before you get too invested. If no plug-in for your testing framework exists, you can write your own plug-in or switch to a less esoteric framework.

The next chore is to configure your browsers. Karma will automatically launch all the browsers you specify, including Chrome, Firefox, IE, and Opera. Additionally, you can launch and run your test in a headless environment with PhantomJS or SlimerJS. Not enough for you? With a little extra configuration, you can get Karma to hook into BrowserStack or Sauce to run your tests on any browser they have available.

You say you want to test a Samsung TV browser? As long as a device has a browser and access over the network, local or otherwise, you can connect manually and run the tests there, too. Just navigate to the host computer's IP address at the specified port and it will do the rest, including rerunning your tests automatically.

After you've chosen your browsers, tell Karma where to find your files. If order is important, you can list the files one by one -- although I don't recommend setting up a project in such a manner. Instead, use a tool like RequireJS to manage dependencies for you. That way, all you'll need to include is something like src/**/*.js and test/**/*Spec.js and you're set. Add files and remove files at your leisure and never touch the configuration file. If you need a smaller hammer than **/*.js, Karma understands JavaScript regular expressions, so dust them off and get going.

For basic projects, that's about it! Tell Karma to watch your file system changes for local development, run karma start, and begin writing tests.

More tools for the job
I have a handful of configuration tweaks I use when testing backbone applications (particularly regarding templates), as well as extra plug-ins and tools you might find helpful. You'll find them all in the full walkthrough, but I'll outline a few here.

I use Jasmine as my test framework. The BDD style reads nicely to me and helps keep track of tests from a higher level. Jasmine is DOM-free, so if you need to test anything with HTML, you will likely want to use jasmine-jquery. It extends Jasmine to include a wide variety of DOM-specific assertions and adds support for loading HTML and JSON fixtures.

Speaking of assertions, if you're writing code for Node.js or only targeting modern browsers, take a serious look at should.js. It's an assertion library that plays nicely with Jasmine and reads clearly. The only problem is that it uses ECMAScript accessor properties (getters and setters), which certain browsers -- particularly IE8 and earlier -- don't support.

While Jasmine provides many testing stalwarts, like mocks and spies, it only recently started supporting the ability to fake XHR requests. The new support has some maturing to do, so I'll stick with my former ally, sinon.js, to stand in for the server. Sinon.js doubles a lot of Jasmine's functionality, but has had the desired ability to fake a server for some time now. It's also easy to set up and use.

All of the testing I do is to ensure my code is covered. I use the Karma plug-in for the istanbul code coverage tool. Built on the shoulders of esprima and escodegenistanbul works well with Karma. By itself, it outputs reports in HTML and LCOV, but the Karma plug-in adds support for text output and Cobertura XML, so Jenkins can understand it. Yes, Karma has plug-ins for continuous integration tools, too.

Together, these tools have saved me tons of time and headache. If you're interested in unit-testing your JavaScript or upgrading your current testing workflow, spend a day or two playing around with them to see if they're right for you, too. If you run into any problems or have any other questions or suggestions, feel free to comment here or reach out via Twitter (@freethejazz).

This story, "Your quick guide to better JavaScript testing" was originally published by InfoWorld.

Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.