Screw.Unit outside the browser

8th May 2009

Screw.Unit seems to be the current favourite means of testing JavaScript code. It has many advantages. It has nice BDD style syntax. It has a custom matchers. It’s easy to extend. It has many lovely things.

It also runs inside the browser, which means it has access to the DOM. This lets you test against the DOM which is handy, but does result in the overhead of having to run a browser for your tests. JavaScript testing frameworks like RhinoUnit don’t run in the browser and as a result can run headless and can run a lot faster. The disadvantage is, of course, that these frameworks cannot test against the DOM.

This isn’t an altogether bad thing. In order to test under RhinoUnit, one must separate view logic from business logic, forcing the developer to think about good encapsulation. It does however still leave you with the question of how to quickly test javascript against a DOM.

John Resig’s Env.js provides one possible alternative. It looks like a solution that would integrate well with RhinoUnit. Another possible solution which I’ve chosen to explore was one which was originally discussed with Fabio Lessa, a colleague of mine, which is to run Screw.Unit tests from inside HtmlUnit.

The following mainfile combined with the subsequent buildr buildfile generates a jar that can be used to run Screw.Unit test suites. The onejar reference in the buildfile allows me to package all the dependency jars into a single jar with the mainfile. This saves me having to add all the dependency jars to the classpath. It isn’t strictly necessary here. (For more details on the subject, see Liz Douglass' post)


package net.randomfocus.screwunitrunner;


import be.roam.hue.doj.Doj;

import com.gargoylesoftware.htmlunit.WebClient;
import com.gargoylesoftware.htmlunit.html.HtmlPage;

public class ScrewUnitRunner {

public static void main(String[] args) throws Exception {
for (String arg : args) {
runTestsForSuite(new File(arg).toURL().toString());
System.out.println(“Screw.Unit tests passed.”);

private static void runTestsForSuite(String suite) throws Exception {
WebClient client = new WebClient();
HtmlPage page;
page = (HtmlPage) client.getPage(suite);
Doj dom = Doj.on(page);

// Allow tests to run.
Integer timeout = 0;
while (“Running…”.equals(dom.get(“.status”).text())) {
if (timeout > 300) {
throw new RuntimeException(“Test in suite [” + suite
+ “] timed out.”);

// Check for failures
if (dom.get(“.error”).allElements().length > 0) {
throw new RuntimeException(“Test in suite [” + suite + “] failed.”);

require ‘buildr’


HTMLUNIT_JARS = [‘xalan:xalan:jar:2.7.1’,

TEST_JARS = [‘junit:junit:jar:4.5’, ‘org.hamcrest:hamcrest-all:jar:1.1’]

repositories.local = ‘./repository’
repositories.remote << ‘’
repositories.remote << ‘’

desc ‘Browser Unit’
define ‘browserunit’ do

project.version = VERSION_NUMBER = ‘scott’

define ‘browser’ do
compile.with HTMLUNIT_JARS
test.with TEST_JARS
package :jar

define ‘packaged’ do
package(:jar).path("lib").tap do |p|
HTMLUNIT_JARS.each do |j|
p.include artifact(j).to_s
package(:jar).path("main").tap do |p|
p.include project(‘browser’).package(:jar)
package(:jar).with :manifest=>manifest.merge(


Running it:
buildr clean package
java -jar packaged/target/browserunit-packaged-1.0.jar screwunit/screw-unit/example/spec/suite.html

Now if we were to try running those against real suites, we’d see that the error reporting is currently nonexistent. Those nice Screw.Unit test reports are lost. Finding a way to represent those accurately is the next big step for making this a viable solution for JavaScript testing outside of the browser.

blog comments powered by Disqus