Instead of replicating the same setup code across multiple test cases, let’s create a base test case that handles this setup chore. The BaseWebTestCase appears like in the next listing:

package com.nealford.art.emotherearth.test;

import net.sourceforge.jwebunit.WebTestCase;

public class BaseWebTestCase extends WebTestCase {
public BaseWebTestCase(String name) {
super(name);
}
public void setUp() throws java.lang.Exception {
super.setUp();
getTestContext().setBaseUrl(
"http://localhost:8080/emotherearth");
}
}

Once the base test case is established, we can subclass it to create tests for pages in the web application. The first test is for the logon page. We want to ensure that the proper elements appear on the page and that it forwards successfully to the catalog page. The TestLogonPage test case is shown in the next listing:

package com.nealford.art.emotherearth.test;
public class TestLogonPage extends BaseWebTestCase {
public TestLogonPage(String name) {
super(name);
}
public void testIntro() {
beginAt("/welcome");
}
public void testLogonElements() {
beginAt("/welcome");
assertFormPresent("welcomeform");
assertFormElementPresent("user");
assertFormElementPresent("gotocatalog");
}
public void testForwardToCatalog() {
beginAt("/welcome");
setFormElement("user", "Homer");
submit();
}
}

HttpUnit has extended the standard assert methods in JUnit to include webspecific assertions. The testLogonElements() method checks to see if the required elements are on the page.

The framework also includes methods that allow the developer to programmatically interact with the application.

The testForwardToCatalog() method lets the developer fill in form values, “click” buttons, and otherwise interact with the web application.

The test runners defined for JUnit also work for JWebUnit. The primary difference is that the web application must be running before you can conduct the tests.

In other words, the test runner will not automatically spawn the web application.

The results appear just as in other JUnit tests, with green and red bars. You do not see any interaction with the web application. All the code is directly accessing the application via HTTP.

Testing complex elements

JWebUnit contains methods for testing sophisticated HTML elements such as tables. The next listing shows a test case that tests some of the table properties of the catalog page.

package com.nealford.art.emotherearth.test;

import java.io.File;

import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.PrintStream;

public class TestCatalogPage extends BaseWebTestCase {
private static String LOG_DIR = "c:/temp/emotherearth/";

public TestCatalogPage(String name) {
super(name);
}

public void setUp() throws java.lang.Exception {
super.setUp();
File outputDir = new File(LOG_DIR);
if (!outputDir.exists())
outputDir.mkdir();
}

public void testCatalog() {
beginAt("/welcome");
beginAt("/catalog?user=Homer");
assertTablePresent("catalogTable");
assertTextInTable("catalogTable",
new String[] {"ID", "NAME", "PRICE", "Buy"});
PrintStream ps = null;
try {
ps = new PrintStream(new FileOutputStream(
"c:/temp/emotherearth/catalogText.txt"));
} catch (FileNotFoundException ex) {
ex.printStackTrace();
}
dumpTable("catalogTable", ps);
}
}

The testCatalog() method of the test case first issues two beginAt() method invocations. We cannot create a test case that goes directly to the catalog page because the welcome page executes code that establishes connection pools and other global resources.

To solve this problem, we issue a beginAt() command that invokes the welcome page and then immediately moves to the catalog page, passing the parameter normally supplied by the welcome page.

JWebUnit includes methods that ensure the presence of a table and that check the contents of individual rows. The assertTextInTable() method verifies that the header row contains the correct elements.
One of the more powerful table tests is the ability to dump the entire contents of the table to a file. The dumpTable() method accepts a table name and a Print-Stream and outputs the entire contents of the table to the file.

The contents of the catalogText file appear in the next listing.

catalogTable:
[ID][NAME][PRICE][Buy]
[1][Ocean][$1,393,456,200.00][Qty:]
[2][Leaves (green)][$3.50]Qty:]
[3][Leaves (brown)]$0.0]Qty:]
[4][Mountain]$2,694,381.3]Qty:]
[5][Lake]$34,563.1]Qty:]
[6][Snow]$2.4]Qty:]

Even the simple tests defined in this chapter begin to show the power of automating tests against web applications. Although the generated output doesn’t look like the original table, it does contain the same data. If you run this test as a regression test, you can compare the contents from one run to another using a diff utility.

Without ever looking at the table, you can determine that something has changed in the output and investigate further. Testing visual output by looking at it is a poor way to test. Eyes miss details, and it is labor intensive to force someone to look at the page whenever you fear something might have broken.

However, dumping the contents to a file where the comparison can be automated ensures consistent appearance and notifies you of unexpected changes.

JWebUnit, like many open-source projects, is short on flash but long on functionality. It provides a powerful framework for automating the consistency and validity of the visual part of your web application, which is the hardest to test by hand.