Your quick guide to better JavaScript testing

Testing JavaScript code without tools is a slog, but choosing the right tools is complicated -- unless you use this handy tutorial to get you started

I have more important things to do than write a post this week, so I've conceded this space to Jonathan Freeman, an ace developer who works for me at Open Software Integrators. JavaScript coders will find his article indispensable. -- Andrew Oliver

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.

[ JavaScript rules the Web -- but how do you harness its power? Find out in InfoWorld's special report, "The triumph of JavaScript." | Show off your coder cunning in InfoWorld's JavaScript IQ test. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]

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:

Your quick guide to better JavaScript testing

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.

1 2 Page 1