In keeping with my belief that there is ridiculous amounts of value in finding bugs before it even gets to QA, this post is about how you might go about doing it with your javascript.

There is nothing inherently so special about javascript that you cannot do automated inspection of it as part of the build. There are even tools to help you do just that. The main one for javascript appears to be JSLint which is a tool which parses javascript against a set of rules. The default way of interacting with it is interaction with the online form which is handy for spot checking one or two files, but that doesn’t solve the automated problem and doesn’t scale.

There appears to be two solutions to these problems.

  1. The first is to use Rhino, an open-source implementation of JavaScript written entirely in Java. Instructions on how to use JSLint in this environment can be found here. With a bit of python/perl/ruby glue code you could easily loop through all your .js files and get some information from them.
  2. The above doesn’t quite get us where we want to be. For that we want integration with a build system(, and making a pretty big leap of faith about who is using javascript, I’m guess it is going to be ant). Again, there appears to be more than one way to do this. The first I found was by using emcascript inside an ant file to write the task. I’m not sure that it would work or not, but there it is. The second way way through a native ant task as part of JSLint4Java. At this point I don’t know which I like better conceptually, and keeping the rule set up to date is going to be a challenge in either case.

One problem with this is the javascript that is embedded in pages on the web server. You could paste in the code to the online version of JSLint or you could just not embed scripts in pages. Instead put them in .js files with are included into the page. While I’m not sure if this is a standard practice or not, this would seem to have the benefit of separating the actual presentation from any dynamic content creation/manipulation which feels like it would be a good idea. It of course also means you now have your javascript nicely encapsulated to pump though JSLint.

But maybe you cannot (or do not want to) restructure your javascript this way? What then? Now we have to turn to such tools as Firebug which gives you all sorts of warnings and errors as you are doing your testing. The problem is that this fantastic tool is only available as a Firefox extension so if you are restricting your product to only IE, or doing things in one browser or not another (both are bad ideas in my book) then you cannot get the benefit of this.

I know just about enough javascript to be dangerous to myself and others so do not know the various ‘best practices’ or more importantly the ‘bad practices’ and ‘common errors’. Firebug for instance taught me about not using eval (or as JSLint says, eval is evil). It also filled it’s console with warnings about document.all and our use (overuse actually) of it. Had I followed the prescribed testing guideline, these and a whole other set of issues would not have come to light. I have since tuned one of my scripts for this project to look for eval and document.all in addition to the other items of interest; it won’t find them all, but some is better than none.