A Blast from the Past: Test Driven Development with JsUnit
Just got back from a day at Six Flags… everyone else is sound asleep while I’m still filled with energy (like Superman, I get energized by a day in the sun) and don’t have anything better to do so I’ve decided to continue the javascript testing series with a blast from the past. As I began to type I realized that I kind of started this series out backwards… my original intent was to showcase the javascript testing frameworks most had heard of and then work my way from unit testing frameworks to BDD frameworks. However, since I started learning BDD in javascript fairly recently, I found it better to tackle those as I was learning them. But tonight I’m going to go back to my roots and explore the first javascript testing framework I ever used (and arguably one of the first on the scene), jsUnit.
The Dirty Details
As I mentioned earlier, jsUnit was one of the first xunit testing frameworks on the scene, with active development beginning way back in 2001. As such, there’s really not much to not like about it as it’s a pretty faithful port of junit, has a server component to run tests from CI with custom ant tasks, and an eclipse plugin that can actually run the jsunit tests from within eclipse (sometimes).
License
General Public License (GPL), although bundled support libraries for the optional server component are licensed under the LGPL and Mozilla Public License (MPL)
Last Updated
The last release was in 2006. However, a check of the repository logs reveals that the last subversion activity on sourceforge was 4 months ago.
Support
As jsunit has been around for 8 years now, it has some pretty good support. There’s a mailing list that, while not very active, does seem to get replies if you ask something on it. Also I have emailed the author in the past for help with the server component to run tests from CI and got very good response.
Okay, Let’s Check it Out!
You can download jsunit 2.2alpha11 from sourceforge. Go get it, extract the archive, rah rah rah. All we care about for these examples is the directories app, css, and img and the files testRunner.html … I’m going to delete everything else. I’ll go ahead and create two more directories, tests for my tests and lib for my actual code. I’d like to take note that in a normal project I’d probably try to keep the jsunit framework somewhere outside of the project, but for this example I’m going to keep it simple so it can be followed.
Next I’ll just create a new html file titled “html5.placeholder.test.html” that includes the required jsunitCore.js file and the javascript file for my system under test:
![]()
Not bad… tests are written in an inline script tag and pretty much follows the pre-junit4 naming conventions.. the functions setup and tearDown will run at the beginning and end of the test, respectively, and test methods begin with the name test. With that in mind, let’s write our first test:
<script type="text/javascript">
var emulator = null;
var content = null;
function setUp(){
emulator = new Html5Emulator();
content = $('<div id="content"></div>')
}
function testInputValueGetsPopulatedWithPlaceholderContents(){
content.append("<input type='text' id='foo' name='foo' placeholder='Enter Something Here'>");
emulator.emulatePlaceholders(content);
assertEquals("Enter Something Here", content.find('#foo').val());
}
</script>
(As usual, I’ve included the jquery library hosted on google for this example and use it for node creation/traversal). Open up the test runner, open the test up using browse, run it and… nothing. Hmmm… I’ll go run one of the included tests. Still nothing. Maybe I accidentally deleted something I needed? I’ll extract the zip to a new directory and run one of the included tests… nothing.
(Scratching head) I don’t get it… I mean really! I’ve used this before on windows and it worked fine! Maybe it’s because I’m running it on linux? The only clue I have is that the “opening file” status says “file:///html5.placeholder.test.html” rather than the full path. Oh well… I’ll just create a soft link to my document root in so I can run the tests against localhost. Sorry for the mixup, this definitely adds a layer of complexity unfortunately.
After linking the jsunit directory to my document root, everything worked… I went on my merry way and finished writing a few more test cases and committed the results.
What I Liked
Pretty faithful junit clone for javascript, easy to use syntax that is a cinch to catch onto if your coming from junit. Also like the fact it runs test suites and even has an ant task for running jsunit tests from ant and reporting the results in junit style output.
What I didn’t like
- The test runner… it hanges a lot when you make mistakes, and it didn’t work well with my linux setup.
- Global functions for test methods… what if I have a global function in my library named “setup”?
- Method names must begin with “test”
- Last release was over 3 years ago
Summary
We have to give jsunit props for being on of the first out there to tackle the problem of test driven development with javascript, for it’s time it definitely broke new ground and allowed us to keep our javascript code clean and well tested. However, in light of all of the other frameworks now out there it doesn’t really bring a whole lot to the table and it’s features seem a bit dated. I will note however that I only tested with the latest release… there might be something fresher in the subversion repository but I did not check.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!













