JspTestCases and Testing Custom Tags with Cactus


JspTestCase was designed to exercise code that depends on the JSP API, specifically that require the pageContext and out objects available in every JSP. This chapter covers testing of JSP custom tags, the main type of J2EE component that uses these objects.

Java Start Sidebar
Then How Can I Test My JSPs?

Cactus can be used to test actual JSPs as well as JSP components. Essentially, you can have JspTestCase map mock versions of objects that the JSP depends on into the appropriate scopes and then forward control to the tested JSP. The output of the JSP can then be verified in endXXX() .

In any case, you should be working to minimize the need for JSP testing. JSPs should contain very little logic, so that you can concentrate on testing the classes the JSPs depend on and still ensure good coverage. The output of a JSP should not vary radically depending on its context—at least not unless the radical variation is encapsulated in a bean or a custom tag. If it the output does vary, maybe the page needs some refactoring.

Java End Sidebar

Custom tags are both powerful and complicated. A custom tag consists of a tag handler class combined with entries in a deployment descriptor file (and possibly a TagExtraInfo class that specifies additional features of the tag). Like a servlet or an applet, tags have a specific life cycle that is maintained by the container. In the case of custom tags, the tag handler class is deeply intertwined with the container code. Because of this complexity, test developers can struggle with creating proper unit tests—after all, how do you unit-test a deployment descriptor? However, in a complicated situation, unit testing increases in importance. You can ferret out subtle container-interaction bugs with ease if you are confident that your code behaves as expected.

Spending the time to understand how a custom tag works, so that this behavior can be replicated in isolation (in other words, in a test), pays off. This section illustrates how to use the context provided by JspTestCase to exercise different types of custom tags, but it is beyond the scope of this tutorial to examine the nuances of, say, the custom tag life cycle in detail. One of the easiest and most practical ways of deciphering custom tag behavior is to examine the generated servlet for a JSP that uses custom tags. Many IDEs offer JSP translation and compilation, along with the ability to view the translated servlet. Also, most servlet containers keep a copy of the JSP servlets somewhere close to the original (usually in some sort of working directory). If your IDE won't translate your JSPs, look for these files. Once you have the translated servlets, spend some time putting in custom tags, recompiling, and examining the generated code. Although the generated code is implementation specific, there are only so many ways to conform to the JSP specification. Examine the output from a couple of different servlet engines and cross-reference your findings with the J2EE tutorial, a reference work, and/or the JSP specification.