Cheesy Title

Using Xvnc within Hudson to run FlexUnit tests

Wednesday, June 4th, 2008

Like most people unit testing Flex applications with FlexUnit in a Continuous Integration environment, I’ve based our setup on Peter Martin’s blog post from January 2007. In it, he describes one of the core challenges of this type of configuration: the fact that the CI server is likely headless. Martin’s solution is to use Xvfb. And this works fine.

But Hudson can do better because someone (Kohsuke, I assume) wrote a plugin for Xvnc. Simply install the plugin and check the checkbox in the job configuration screen:

Hudson will then automatically start up a Xvnc session and set the DISPLAY environment variable to the appropriate value and then shut down the session when the build is complete. One advantage this has over the Xvfb method is that if you have multiple Flex projects building simultaneously, each build has its own X session. While this has yet to be an issue for our projects, it seems like a good idea. The architecture of FlexUnit actually makes simultaneous builds a bit tricky. In another post, I’ll cover how Hudson can solve this problem too.

A word of warning:
Before using this plugin, you obviously have to have Xvnc installed. What’s less obvious (although sensible) is that you must also set a password. You do this by running:
$ vncpassword
This has to be done as the same user Hudson runs as.

FlexUnit reports in Hudson

Sunday, June 1st, 2008

As a follow-up to my post about using the FlexUnit results produced by the flex-mojos Maven plugin to produce a unit test report, I wanted to point out that this same technique can be used within the Hudson continuous integration server.

Here’s what the config looks like:

(Note that we’re also using Hudson’s JavaDoc support to publish the produced ASDoc).

This gives you all the nice Hudson unit testing support like graphs of tests per build:

UPDATE – With the Flex Mojos 1.0 release, the output directory for FlexUnit tests has changed. It’s now surefire-reports, so the Test report XMLs value should be **/target/surefire-reports/*.xml.

Generating FlexUnit Test Reports with Flex Mojos

Thursday, May 29th, 2008

The flex-mojos project supports unit testing of Flex code, but it doesn’t use Maven’s default surefire plugin for running tests. As a result, you need to make a slight tweak to your pom.xml file:

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-report-plugin</artifactId>
      <configuration>
        <reportsDirectory>${project.build.directory}/test-reports</reportsDirectory>
      </configuration>
  </plugin>
  </plugins>
</reporting>

Here’s some sample output:

UPDATE – With the Flex Mojos 1.0 release, the output directory for FlexUnit tests has changed. It’s now surefire-reports, so you can simply include the surefire-report plugin in your pom.xml file without any configuration:

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-report-plugin</artifactId>
  </plugin>
  </plugins>
</reporting>

Working with SVNKit

Tuesday, May 27th, 2008

We’re doing a big project at work that involves splitting up a large codebase into lots of little projects. The general methodology is:

  1. Create a new directory in Subversion.
  2. Copy some stuff from the main codebase into the new directory.
  3. Compile/fix
  4. Package
  5. Delete files from the codebase and replace with the packaged jar.

One of the problems that’s come up is that the codebase is a moving target; people not involved in the extraction are making change all the time. I use Fisheye notifications to let me know when a change has been made to the codebase, but that requires me to remember to set up the notification.

So I decided to write a Maven plugin that would iterate through all the files in the extraction target directory and see if there are newer versions in the codebase. This means getting the info per file up until the point it was copied and then checking the URL the file was copied from to see if there are newer revisions.

I started doing this by passing calling the Subversion command line client with the –xml option and then using some XPaths to extract the necessary bits. There were two problems with this approach:

  • svn and svadmin had to be on the path
  • the code wasn’t readable

The former wasn’t that big a deal locally, but when I committed the unit test that used svnadmin, the tests failed on the CI server because svnadmin wasn’t on the path. The second was obvious while I was writing the code, but figured I’d deal with it later.

Rather than have svnadmin added to the path, I took a look at svnkit and found the API to be pretty clean. Things I really like (in no particular order):

  • Very OO.
  • Defaults to using the default Subversion authentication store.
  • Good use of File objects – cut way down on calls to file.getAbsolutePath()
  • Really helpful for unit testing – e.g. SVNURL objects can be compared against one another

Things I didn’t like:

  • Wasn’t super-intuitive what methods were in which Client class – why is doInfo() in SVNWCClient and not in, say, SVNLogClient
  • Methods could be overloaded more with defaults that matched the command-line
  • SVNWCClient.doAdd() only accepts one File at a time
  • Latest version isn’t in Maven Central

But the biggest issue is speed, at least it seems to be. It sure seems slower when running my unit tests in Eclipse, but Hudson doesn’t show a big difference. Build #13 is when I introduced a minimal about of svnkit just to get svnadmin functionality working. Build #20 is all svnkit and is actually a few seconds faster. I’ll have to look more at this going forward.