When MailReader - an example application bundled with the Struts Action framework - was created six years ago, most Java developers had yet to discover unit testing. Consequently neither the Struts framework nor the MailReader were created test-first. Since then, we've bolted a few unit tests onto the Action framework, but the MailReader for Struts 1.2 still has no developer tests at all.

Over the last 10 years, testing has become more popular with developers. Much of this popularity can be attributed to the JUnit framework: a simple effective tool for many teams. But JUnit isn't enough. It makes writing tests easier, but we still have to write the tests. Many of us despair at the notion of writing even more code to test the application code we're already writing. What we need are tools that can write most of the tests for us.

Software Agitation
Software Agitation exercises and analyzes Java binary code and generates observations about how the code behaves. Developers can quickly create tests based on these observations, often without writing any new code. This article walks through using Agitator to create unit tests for the Struts MailReader application.

The flagship software agitation tool is Agitator by Agitar Software. The tool rapidly creates observations of code behavior, and helps the developer determine if the code is working as expected or see if Agitation has revealed unexpected behavior.

From within the Eclipse IDE, we can promote a valid observation to a unit test, or we can trace through the code to change the behavior. If the application code is valid, but the range of acceptable values needs to be adjusted to demonstrate correct behavior, we can assign custom factories to a parameter. Along with factories, Agitar provides for automatic "Domain Experts" that we can use to test code peculiar to our own API or to test code peculiar to frameworks like Struts.

Getting Started
After launching Agitator's version of Eclipse, we can create a new project using the "Java Project with Agitation" template. For this project, we point Eclipse at the root of the Struts 1.2 source tree. We have a library of JARs for the Struts 1.2.8 distribution, which are easy to add to the Eclipse Build Path as "External JARs" along with a reference to the servlet JAR for Java 2.3.

The one other thing we have to do is unselect irrelevant packages as source folders. In Struts 1.2, the MailReader source is mixed in with packages for the rest of the framework distribution. In the end, we have two source folders: src/example and web/example.

We can open the "Agitator" view from the menu bar, and "Agitate" the package containing the five MailReader business classes [org.apache.struts.webapp.example.memory].

A New York minute later, Agitator has done its thing. Three classes are in good shape, with 100% code coverage. Two of the five classes were flagged with warning symbols. The MemoryDatabasePlugIn class weighed in at 70% coverage. The key class, MemoryUserDatabase, had 38% coverage. The code coverage for each is shown in Table 1.

Let's start with the low-hanging fruit and review the three classes with 100% coverage: MemorySubscription, MemoryUser and TestUserDatabase.

MemorySubscription and MemoryUser represent database entities. Being standard JavaBeans, these classes were easy for Agitator to test. Each of the JavaBean properties has a standard unit test to ensure that the field is set by the parameter.

The only two methods lacking tests are the constructor and toString. The constructor is simple, but, still, Agitator has generated some essential tests like:

this.getHost() == host
this.getUser() == user
Table 2 - MemorySubscription Constructor Method
    public MemorySubscription(MemoryUser user, String host) {
       super();
       this.user = user;
       this.host = host;
    }

We can mark these as unit tests to prevent simple silly mistakes like assigning a parameter back to itself.

The toString method creates a textual representation of the class. The method looks hard to test with a known set of input data. For now, we can change the method's property to "Exclude from testing."

    public String toString() {

      StringBuffer sb = new StringBuffer("<subscription host=\"");
      sb.append(host);
// ...
      if (username != null) {
        sb.append(" username=\"");
        sb.append(username);
        sb.append("\"");
    }
    sb.append(">");
    return (sb.toString());

Reviewing observations for the other classes and methods, we find several other assertion candidates. Each of these candidates corresponds to assertions that we might have made in a conventional JUnit test. For example, setting the pathname property also sets the pathnameNew and pathnameOld fields. We didn't have to express that fact to Agitator. On its own, the software observed that

@EQUALS( this.pathnameOld, "database.xml.old" )

All we have to do is confirm that the observation is an assertion that we should test. If we were writing a JUnit test, we'd have typed-out code like:

assertEquals( this.pathnameOld, "database.xml.old" );

With Agitator in play, we just point and click.

Not bad. After only a few minutes of clicking around, we have almost 80 test points. Perhaps most important, these test points will automatically evolve with the code - something that hand-coded tests can never do.

Now, what's the problem with the other two classes that had less than 100% coverage?

Agitator displays a legend next to the lines in a class to show how often each line of code is being reached by Agitation, or if the line was even reached in the first place. In the case of MemoryUserDatabase, we can see that there are a lot of red lines after an input-output call, indicating that the code isn't being reached. Clicking through, it's easy to see why many of the Exceptions were being thrown: "File Not Found."

The "Memory" implementation of the MailReader data access object loads a list of Users and their e-mail Subscriptions from an XML document into an object graph stored in main memory. (Hence, the package name.) The file wasn't found because Agitator had no way of guessing the right file name. For now, I mark the problematic classes or methods "Exclude from testing" - at least until we can learn a bit more about Agitator.

Excluding the eight input-output members lowered the overall test coverage. But, even so, in only a few minutes, we were able crank up Agitator for the first time, create over 80 test points, and yield a test coverage of around 40%.

Agitating Struts
The Agitar website hosts a 47-minute "webinar" on its Struts Expert. I watch this and skim the documentation.

Now that we've had a taste of Domain Experts, let's put the Struts Expert through its paces.

LogonAction
The webinar mentioned the standard Struts Expert, which can be found and enabled on Agitator/Plugin Experts menu. Eclipse is not displaying any red marks, so the code seems to be compiling. Let the Struts Agitation begin!

After Agitating the MailReader code base with the Struts Expert enabled, a number of red marks popped up in the Package Explorer. Drilling down, we find error icons next to the Action execute methods. The pop-up hint explains that the Struts configuration can't be found. Meanwhile, the Console view contains several warnings that a ServletContext can't be found either.

Returning to the Agitator menu, we find the likely item "Create J2EE Environment." A wizard leads us through creating a default environment, and even includes a "Test" button so we can check our work.

Now that we have a J2EE environment, for good measure, we pop back to the PlugIn Experts menu and enable the J2EE expert too. After another Agitation, there are still red marks, but the messages are functional rather than systemic, with remarks like "Coverage failed" and "Outcome failed".

Opening up LogonAction, we find the Struts We already have 67% coverage, and the execute method has partitions for the various Struts outcomes: registration, logoff, logon, success, and welcome. Several class invariants were generated, but only "this.getServlet() != null" looks like a worthwhile assertion.