Extreme Struts Development with Integrated and Ongoing Testing

Integrating ongoing testing into your development environment doesn't mean you're practicing XP; but on the other hand, you can't practice XP without it. In fact, the approach of integrating ongoing testing into your development process is one of the aspects of XP that's been most widely adopted in mainstream development ”even in shops that would never fully embrace XP completely. This adoption has occurred for good reason: It results in better quality code, reduces rework , and helps isolate bugs faster. So, let's get into it.

An Overview of Testing Approaches and Tools

One of the big problems in testing programs that use application servers is that so much of their functionality comes from services the container provides. Put another way, how do you test a Struts Action class without actually deploying it and using a browser to test the pages yourself?

There are two ways people solve this problem. The first is to write code that pretends to be an application server and sets up request/response objects and so on to run your code and test it. This is referred to as mock testing . (It's also called m ock object testing because you have to create mock objects to do it.) This can get complicated, and it's really only a substitute for testing in the container anyway. Just because you pass the tests using mock objects doesn't mean your code is guaranteed to run in the Web container.

The other way this problem can be solved is to do what's referred to as in-container testing , or testing your code after it's actually deployed in the container. The challenge with this is writing class-level unit tests and running them in the container. For example, how can you easily test every validation your Struts form bean performs without going to a browser screen and trying to enter every combination of bad data you test for?

Fortunately, the open source developers who came before you have addressed these problems. The options you'll see in this chapter for performing exactly these types of testing are pretty impressive. They're impressive both because of the effort that went into building them and for how amazingly easy they are to use.

The next sections review the tools you'll use for testing and how they work together. Following that you'll set up and run both mock object and in-container tests on the Hello World application you just finished building the Ant script for. You'll also integrate the tests directly into the Ant script so that they can be executed every time you do a build ”this is how you build quality directly into your development process. Now that's extreme!

JUnit: The Engine That Drives Ongoing Testing

JUnit is an open source project for software testing developed originally by Erich Gamma and Kent Beck. It's maintained at SourceForge at http:// sourceforge .net/projects/junit and, in addition, has its own Web site at http://www.junit.org. JUnit was developed to provide a simple framework for collecting and performing unit tests on Java code. It's a solid, mature product and is in widespread use.

JUnit has grown into much wider use since the development of Ant tasks that allow JUnit testing to be incorporated directly into Ant build files. Many JUnit users have never seen the original GUI that was delivered with JUnit ”they simply write JUnit tests and check them in so that they are run as part of the ongoing build process. This is how the tests developed in this chapter are run.

Honestly, learning much more about JUnit is beyond the scope of this chapter. Because all the tests you create use JUnit under the covers, there's really no need at this point to go into much more detail on JUnit itself.

If you're interested in learning more about JUnit, we recommend that you review the documentation on its site, beginning with the essay , "Test Infected: Programmers Love Writing Tests."

Cactus: A Framework for In-Container Testing

Cactus is a subproject of The Jakarta Project (just as Struts is). Its purpose is to provide a framework for in-container testing. The Cactus project home page is at http://jakarta.apache.org/cactus.

This chapter covers both the in-container and mock object approaches to testing; Cactus is used only in the in-container portions of the chapter. You'll actually use an extension to JUnit that enables you to run Cactus tests from JUnit (which means they can be integrated as JUnit tests directly into the Ant build file).

You'll get into Cactus more deeply in later sections of this chapter when you actually write and run in-container tests for the Hello World application. It's important, however, at this point to introduce it and let you know where it fits in the overall picture.

StrutsTestCase: A JUnit Extension for Testing Struts Applications

StrutsTestCase is an extension of JUnit that enables you to easily build JUnit-based test cases using both mock object and in-container testing for Struts applications. StrutsTestCase is hosted at SourceForge (at http://sourceforge.net/projects/strutstestcase) and is distributed under an open source license.

StrutsTestCase was developed specifically to provide developers the ability to develop JUnit-based tests for Struts applications. It implements a series of classes that allow for mock object testing of Struts applications. In addition, it provides the ability to implement the same functionality using in-container testing with Cactus.

A copy of StrutsTestCase is provided on the CD-ROM accompanying this book (in addition to versions of Ant, Cactus, JUnit, and the other packages required for this chapter).

Before diving into the details of configuring your system to allow you to run all this software, let's begin by first writing a test case using StrutsTestCase.