The Apache Project is probably the biggest open source technology project besides the GNU/Linux kernel (and distributions). Best known for its web server, the Apache group also has a very lively and productive Java group known as Jakarta. The Jakarta group is best known for the Tomcat application server and the Struts framework, but there are many, many, many other projects under the Jakarta group.

Enter me….

Here at the new job, we use the Turbine and Torque frameworks for our web application. Turbine is basically Struts on steroids–on top of providing a high level interface for handling web requests, it also includes a number of services (not “web services”, just “services”) such as security (things like access control lists for the site, user management), XML/XSLT transformation, form validation, yadda yadda yadda. The Turbine project is fairly young, and that means one thing–the documentation sucks. What little documentation there exists is written by the guys the wrote the framework, so they understand how everything works, which leads them to leave out important bits and pieces that they often assume is common knowledge. Often the best source for information is the Turbine user mailing list, but unfortunately, the archives are often unaccessible…..fortunately, most other users are in the same boat, so simply posting to the list generally gets you a quick answer, regardless of how ignorant the question is.

So after a month or so of hacking, I’ve got a decent handle on Turbine. Great. Now, we’re in the middle of a redesign of the entire app, and I’ve been chosen to head up the testing/QA department, so I’ve been looking at various testing frameworks. The tried and true framework is JUnit, a Java-based unit testing framework. While JUnit is very powerful, it is better suited to standalone applications, as you don’t have to worry about instantiating the application server container objects (like HttpRequest, HttpSession, etc) to run your tests. So, being the clever folks they are, the Jakarta group has written a framework on top of JUnit called Cactus. Cactus allows you to instantiate all your container objects within your tests, allowing to write the tests on a client machine, move the tests to the server, and test either via the command, a tool like Ant, or via web interface. Fantastic, I say….sign me up….

But….

Cactus is build for straightforward web applications–that is, an app that doesn’t use a framework like Struts or Turbine. These framework generally hide things like HttpRequest from the framework, wrapping them in other objects for easier state management. So is Cactus is unusable? Not according to the Turbine users list. Several Turbine developers were nice enough to post code fragments for using Cactus to test Turbine classes. Great! But then, no one was nice enough to post information about how to configure Cactus to properly use Turbine (which is where I am right now). But Brian, why don’t you just read the documentation on the Cactus site? you ask? Well, follow the Cactus link above and you’ll find the site is about the 1.5 dev release, which means it isn’t technically a release. To download Cactus 1.5, you’ll have to find the latest nightly build, and hope it works. Nice eh? Again, it’s like the developers are doing this project for themselves, and if you can catch on, you can use it too.

So I’ve running around in circles today. I’ve come dangerously close to getting a real, live unit test for Turbine working with EasyMock, but Ant is being kinda dumb about a classpath issue at the moment. Currently, I’m printing the manual for Maven, yet another poorly documented build tool from Apache….this one, however includes automagic Cactus testing, so it’s at least worth a try.

Posted on 29 May 2003