A modern web page does a lot of things, hence the term web application has become more commonly used over the last year. A consequence of this is that we are crafting widgets and entire modules using JavaScript, or at least in some language that eventually ends up being “compiled” to JavaScript.

Where there is code there should also be tests. And the tests need to go green every time the code is changed. You are testing your client side code, right?

JavaScript testing

As with everything else, there has been an evolution of testing frameworks for JavaScript. From tests that run in a static HTML page like QUnit, to the innovative js-test-driver that captures (multiple) browsers and runs tests on them using a server component, and finally to the newest kid on the block, Buster.js, that does everything and more.

Using Buster, you can have your tests run very quickly on PhantomJS, a headless WebKit browser based on the V8 JavaScript engine. (It uses JavaScriptCore with JIT compiler). It is also easy to capture multiple browsers, and thus run the tests on multiple platforms at once.

We have recently set up our Continuous Integration server, Jenkins, to run our tests written in Buster. In addition, we added linting and checkstyle reports using JSHint.

Configuring Jenkins CI

To accomplish this, go configure your project in Jenkins, find the Build section, and add the following build steps (in order) using Execute Shell:

1. Start the Buster server, and make the Phantom browser connect to it. (The buster_phantom.sh script is included at the end of this post.)

2. Run the tests, and make Buster output xUnit formatted XML.



3. Cleanup by stopping Buster and Phantom.



4. Run JSHint with the —jslint-reporter flag.



5. Run JSHint with the –checkstyle-reporter flag.



Finally, under Post-build Actions, add these steps:

1. Publish Checkstyle analysis results and Publish JUnit test result report.



2. To mark the build as unstable when one of the JSHint checks fail, add Report Violations.



3. If you have not done so already, you should add email notifications when the build goes unstable.

The script used to start Buster and Phantom, are embedded below from https://gist.github.com/4285257:

Final thoughts

It should be quite easy™ to run the tests on more platforms, perhaps even using a browser provider such as Browserstack or Testling.

If you have an Open Source project going on, you can run the tests using Travis CI, see this guide by QMetric.

And the result? Beautiful graphs on the project page, sure, but more importantly, the tests are run every time your code changes, and you get feedback when something is wrong.

How do you run your JavaScript tests? Let us know in the comments!