Featured White Papers

Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Testing J2EE applications

Recipes for testing enterprise apps

By Scott Stirling, JavaWorld.com, 08/30/04

Print
Feedback

We advocate testing an application by testing its components thoroughly and then integrating those components as simply as possible. Specifically, "integration" for us is little more than choosing which implementations of various interfaces to use and then creating an application entry point object with references to those implementations. Which logging strategy do we use? How about log4J! We know that our components work with any implementation of the logging strategy interface. What kind of model? A JDBC-based (Java Database Connectivity) one, although our controller really only knows about our model interface, so an in-memory implementation, or one based on Prevayler will do. To us, this is integration. As a result, we tend not to emphasize end-to-end testing for correctness, but rather to give us confidence that we have built the features we needed to build. Object tests tell you whether you built the thing right; whereas end-to-end tests help you decide whether you built the right thing.

There are certain aspects of J2EE applications that people associate with end-to-end tests rather than object tests. These include page flow—or navigating a Web application—and using container services, such as security and transactions. We discuss these topics in recipes in this chapter, showing you how to test these behaviors in isolation—as object tests. We do not want to give the impression that we shy away from end-to-end tests—that is, testing an application by simulating the way an end user interacts with it through its end-user interface. We use end-to-end tests to play a different role than other programmers do: we use end-to-end tests to help us determine whether what we have built actually does what our customers need. We no longer see JUnit as the best tool available for testing an application from end to end. We use Fit and its companion tool, FitNesse.

Note: We are certainly not the only people who see end-to-end tests in this role: we got the idea from the Agile community at large. Still, while Agile developers remain in the minority, organizations will continue to see end-to-end tests as their primary tool for validating software, an approach that we feel ultimately wastes resources that could be better spent ensuring correctness from the inside out through programmer tests.

We will describe Fit only briefly. Imagine writing tests entirely as spreadsheets and word-processor documents. You could annotate your tests with plain-language descriptions of what they verify— mix code and text together so that both the programmers and the nonprogrammers can follow them. Now imagine running those tests through software that decorates your documents green for the parts that are right (tests pass) and red for the parts that are wrong (tests fail). That is Fit, and it allows those with business knowledge to write executable tests, even if they are not programmers. FitNesse is a Wiki that can execute Fit tests, providing an excellent way to organize them and collaborate on them. Many people have designated FitNesse as "the way they do end-to-end tests." (Pronounced "fit-NESS." Micah Martin, cocreator of FitNesse, tells the story how Uncle Bob (Robert C. Martin) was tired of executing Fit tests from the command line and wanted to execute them "with finesse.")