I’m going to go out on a limb and posit that a few of you have attempted, and possibly succeeded, at integrating JsUnit into an automated build process. Assuming that is true, you people are off my Christmas card list for not blogging about it in such a way that it is discoverable by Google. (And that includes you, Miller).

The sole exception to this is honorary hillbilly Toby Henderson who provided enough insight in the comments to Jeremy Miller’s post mentioned so disparagingly above. From that, I was able to come up with the following NAnt task (and Jayzus only knows how this is going to look in an RSS reader):

<target name="jsunittests">
  <property name="jsunit.port" value="9123" />
  <property name="jsunit.authority" value="localhost" />
  <property name="jsnuit.vdir" value="AdventuresInPlaid" />
  <property name="jsunit.acceptor.partialurl"
    value="${jsunit.authority}:${jsunit.port}/jsunit/acceptor" />
  <property name="jsunit.url"
     value="&quot;http://${jsunit.authority}/${jsunit.vdir}jsunit/testrunner.html?testPage=${jsunit.authority}/${jsunit.vdir}JsUnitTests.aspx&amp;autoRun=true&amp;submitresults=${jsunit.acceptor.partialurl}&quot;" />
  <property name="jsunit.browserFileNames"
     value="&quot;${programfiles.dir}internet exploreriexplore.exe,${programfiles.dir}Mozilla Firefoxfirefox.exe&quot;" />
  <property name="jsunit.log" value="logs" />
  <property name="jsunit.resourceBase" value="" />
  <property name="libs" value="" />
  <foreach item="File" property="filename">
    <in>
      <items>
        <include name="appBookedIn.WebJsUnitjavalib*.jar" />
      </items>
    </in>
    <do>
      <property name="libs" value="${libs}.lib${path::get-file-name(filename)};" />
    </do>
  </foreach>
  <property name="libs"
    value="${string::substring(libs, 0, string::get-length(libs) - 1)}" />
  <exec program="java" workingdir="appBookedIn.webjsunitjava"
        commandline="-Dport=${jsunit.port} -DbrowserFileNames=${jsunit.browserFileNames} -Durl=${jsunit.url} -DlogsDirectory=${jsunit.log} -classpath &quot;.binjsunit.jar;.config;${libs}&quot; junit.textui.TestRunner net.jsunit.StandaloneTest" />
</target>

Assuming that’s copy-and-pastable into your own script, I’ll move on.

The properties almost certainly should be moved outside of this target, of course. I’ve included them all here for convenience. Some of them are machine specific so putting them at the top means you can override them with a local properties file.

The <foreach> loop in the middle was borne out of frustration. It will look through all the .jar files in the JsUnit lib folder and create a semi-colon-delimited list of them. This is then passed into the classpath for the <exec> task which launches the whole thing. My guess is that Toby used an older version of JsUnit because it appears there are a lot more libraries involved now. After about the third or fourth time running the task with a manually-entered list of libraries and having a ClassDefNotFound error come up, I sought out some help to just dump them all in with the <foreach>.

Word of caution: the config folder included in the classpath contains xwork.xml. The part that caused us the greatest trouble was a message “Error loading configuration file xwork.xml”. This was because we were including the path to the xwork.xml file explicitly, rather than the path to just the config folder. It was the Ant file for JsUnit itself that eventually led to our salvation.

So between this and the recent announcement that my wife is pregnant, all is well in Hillbilly House.

Kyle the Expectant