◆ Problem
You want to test page-to-page navigation in your Struts application, preferably with- out starting Struts.
◆ Background
Testing navigation rules using End-to-End Tests is expensive. We described the issues in recipe 13.1. Here, we are interested in verifying the navigation rules for a Struts application. Using End-to-End Tests to do this is no less expensive for a Struts application than for any other type of web application. Using a framework does not make End-to-End Tests any simpler than not using a framework. What Struts does, however, is provide a way to test navigation rules without resorting to End-to-End Tests, something that makes isolated navigation tests remarkably easy.
◆ Recipe
The most direct approach you can use is to verify the content of struts-config.xml using XMLUnit. Here we will show a few example tests, but for more details on veri- fying XML documents, see chapter 9, “Testing and XML.” We will use the sample struts-config.xml currently posted at the Struts web site (http://jakarta.apache.org/
struts/index.html). Listing 13.5 shows some tests.5
package junit.cookbook.coffee.web.test;
import java.io.*;
import junit.extensions.TestSetup;
import junit.framework.*;
import org.custommonkey.xmlunit.XMLUnit;
import org.w3c.dom.Document;
import org.xml.sax.InputSource;
public class StrutsNavigationTest extends StrutsConfigFixture { private static Document strutsConfigDocument;
public static Test suite() { TestSetup setup =
Listing 13.5 XMLUnit tests for struts-config.xml
5 The tests here will fail without an internet connection, because XMLUnit will try to validate the XML document against its DTD. For further details, see recipe 9.2, “Ignore the order of elements in an XML document,” and read the section entitled, “Network connectivity and the DTD.”
520 CHAPTER 13
Testing J2EE applications
new TestSetup(new TestSuite(StrutsNavigationTest.class)) { private String strutsConfigFilename =
"test/data/sample-struts-config.xml";
protected void setUp() throws Exception { XMLUnit.setIgnoreWhitespace(true);
strutsConfigDocument =
XMLUnit.buildTestDocument(
new InputSource(
new FileReader(
new File(strutsConfigFilename))));
} };
return setup;
}
public void testLogonSubmitActionExists() throws Exception { assertXpathExists(
getActionXpath("/LogonSubmit"), strutsConfigDocument);
}
public void testLogonSubmitActionSuccessMappingExists() throws Exception {
assertXpathExists(
getActionForwardXpath("/LogonSubmit"), strutsConfigDocument);
}
public void testLogonSubmitActionSuccessMapsToWelcome() throws Exception {
assertXpathEvaluatesTo(
"/Welcome.do",
getActionForwardPathXpath("/LogonSubmit", "success"), strutsConfigDocument);
} }
The Struts configuration file combines navigation rules with the mapping between locations and URIs. When an action forwards to another action, it uses a navigation rule; whereas, actions that forward to page templates (a JSP or a Velocity template) are location/URI mapping rules. In this way, the Struts configuration file plays the role of navigation engine as well as location mapper, as we described them in rec- ipe 13.1. You can use the same approach to test location mappings as for naviga- tion rules.
TE AM FL Y
Team-Fly®
521 Test navigation rules
in a Struts application
◆ Discussion
There are a few things to notice about the tests in this recipe. First, notice that we load the Struts configuration file using one-time setup (see recipe 5.10, “Set up your fixture once for the entire suite,” for more about how to use TestSetup).
Next, notice the methods getActionXpath(), getActionForwardXpath(), and get- ActionForwardPathXpath(). These methods translate the concepts of “action” and
“action forward” to the corresponding XPath locations in struts-config.xml. Not only do you not need to remember the various XPath expressions for actions and action forwards, but you also avoid duplicating those expressions in case of future changes in the Struts Configuration file DTD. We extracted a fixture class Struts- ConfigFixture and pulled those methods up into the new fixture class for reuse (see recipe 3.4, “Factor out a test fixture” for more about extracting test fixtures).
Listing 13.6 shows these methods.
package junit.cookbook.coffee.web.test;
import org.custommonkey.xmlunit.XMLTestCase;
public abstract class StrutsConfigFixture extends XMLTestCase { protected String getActionForwardPathXpath(
String action, String forward) {
return getActionXpath(action)
+ "/forward[@name='" + forward + "']/@path";
}
protected String getActionXpath(String path) {
return "/struts-config/action-mappings/action[@path='"
+ path + "']";
}
protected String getActionForwardXpath(String action) { return getActionXpath(action) + "/forward";
} }
Notice the incremental style of the tests. This is a good approach to take when ver- ifying XML documents with XPath, because when an XPath-based assertion fails, there is no easy way to determine the cause. Perhaps you mistyped the name of an XML element three levels down in the expression, or you forgot to include an “at”
sign (@) for an attribute. By writing many small, increasingly specific tests, it is easier to determine the problem by observing which tests fail. For an action map- ping, consider these three tests:
Listing 13.6 A sample fixture for struts-config.xml tests
522 CHAPTER 13
Testing J2EE applications
1 Is the action configured at all?
2 Does it have any forwards?
3 Are its forwards correct?
Writing three tests rather than just the third one makes it possible to say that, for example, if the second and third tests both fail, then there is a problem with the Struts configuration file—there is an action without a forward.
◆ Related
■ 3.4—Factor out a test fixture
■ 5.10—Set up your fixture once for the entire suite
■ 13.1—Test page flow (navigation rules)