JavaScript is mainly (but not only!) clientside language. Therefore it poses some problems for developers who use unit testing in their projects. I’m going to point out most of them and solve bit by bit in next articles. If you don’t need explanation of this term itself, proceed right to the JavaScript Issues title.

Unit Testing

In short: We’re writing tests for our application which are independent of each other. We may quickly execute set of them as we modify the code. The new application is error-free if all go positively.

Unit Testing is connected with Agile methodology and techniques of producing a software such as Extreme Programming (XP) or Test-driven development (TDD). They assume that changes in application should be made frequently and in small portions. Unfortunately, it’s equivalent to frequent errors. Thanks to Unit Testing we are able to detect them rapidly.

Test-driven development

My team has created very innovative solution, but we’re still looking for a problem to go with it.

Writing tests for the application doesn’t have to follow after writing it. TDD is an excellent example of it. The process of creating software starts with writing an set of automatic tests which are checking if the given functionality is acting correctly. After that follows an implementation. If it passes all of the tests, we’re done.
It is necessary here to note that Unit Testing has also certain

Disadvantages

Writing tests is a responsible task. It is hard to show all cases, in which our code may create errors. In the case of TDD some tests will be written only as untypical circumstances cause the crash of our application. Also although out code passes an examination, it may be written at the very least strange way. We must care about its quality and obey certain principles.

Although, thanks to Unit Testing it is easier to work with more people on one project. Once an error is detected, you can easily locate it in the future. We know new functions won’t spoil the older ones. Therefore above technique is widely applied in Open Source software.

JavaScript Issues

As I said, JavaScript is clientside language. The name suggest all the tests must be performed on the client side or at least  simulate client environment. For instance, the correctness of implementation depends on whether you run it in Firefox, Opera, Safari, Chrome or (damn) Internet Explorer. It is also difficult to pretend which version of above browsers will be used. And how, the hell, to install Microsoft browser on our OSX?

Above all, we want to run all the tests automaticly, as we save modified code. Because they have to run in some browser, it is difficult ot automate this process, and the only solution that comes to our mind is pressing F5 again and again.

Moreover, some tests written by us may not take place fully automatically. How do we know if the drag & drop works? Did the user see that blinking message?

And the lovely global variables. Running tests in the same document is certainly not good idea. Therefore we have to refresh at each and every test.

It should be mentioned JavaScript is not just a browser. There are such gems as Rhino (Java implementation of JavaScript) or Node.js (Event-based JavaScript web server).

Different solutions

One of the first is old-good JS Unit framework. It runs tests on actual browser – not simulated like in case of RhinoUnit or Crosscheck (which arose as result of rewriting the JavaScript engine to Java).

Another kind of Unit Testers are purely JavaScript solutions like qUnit, JSSpec or JSUnitTest. First of them is used i.a. by jQuery, second one by MooTools, and third grew up from Prototype’s unittest.js. Writing tests with them is a pure pleasure. However batch executing of them in different browsers requires few tricks.

Here appears the JsTestDriver written in Java, which lets e.g. to run tests in different browsers, on different computers, directly from console. This is almost perfect solution.

However, Mozilla went farther and is developing a Test Swarm which works similarly to the JsTestDriver server, therewith that we can start our tests on everyone’s browsers who will be willing to take part in the program – they would only have to go on a shown website up. We don’t have to start our own server and connect different browsers up to it. The community will do it instead of us. However, at the moment amount of participators is infinitesimal, so only we can do is to wait for a greater interest.

Intresting part of Unit Testers make GUI Testers such as Selenium or Canoo. They are bridge between programmers and  testers who perform tests that cannot be made automatically. An example question: ‘Is product semi-transparent as you drag it?’

There’s lot of other great frameworks like: Screw Unit, JSpec, Scriptaculous Test Unit, Jasmine, YUI Test, FireUnit or DOH. I’ll describe the most intresting of them in next articles. In the meantime you may compare some using table below:

Usefull links and articles

• List of JavaScript Unit Test Frameworks on Wikipedia
• Unit Testing Guidelines
• Unit Testing for Non-Programmers