Summary

Important 

Testing should occur throughout the software lifecycle. Testing should be a core activity of software development.

Test cases should usually be written before code. Instead of considering application code as the sole deliverable, test cases, documentation (Javadoc and other), and application code should be kept in sync, with the test cases being written first. If you can't write a test for a piece of code, you don't know enough to write the code itself. A test that isn't up-to-date is useless.

Unless tests are easy to run, they won't be run. It's vital that unit tests can be run automatically, and that there is no need to interpret the results - there should be a single indication of success or failure. Ant can be used to automate tests written with JUnit. It's important to invest a little time early in the project lifecycle in establishing testing conventions and streamlining the testing process so that all developers can efficiently write and execute tests.

Especially in the case of web applications, stress testing is vital. Unsatisfactory performance is a serious risk in enterprise software development, and should be tackled early, through a proof of concept, while it isn't prohibitively expensive to modify the application's design.

Testing J2EE applications involves many different tests. We've considered the following test strategies:

• Unit testing of classes (from all architectural tiers) with JUnit. As we've seen, the simple, easy-to-use, JUnit testing framework can be used as the basis of our testing strategy. Unit testing is usually the most important type of testing.

• Testing EJBs with remote interfaces using JUnit test suites running in a client JVM.

• Testing EJBs with local interfaces using Cactus (an open source framework built on JUnit that allows tests to be run within the application server).

• Unit testing of web-tier classes using JUnit and test implementations of Servlet API interfaces such as HttpServletRequest and HttpServletResponse. This enables web-tier classes to be tested outside the application server, making testing more convenient.

• Acceptance testing of the web interface via "screen scraping" web tools such as HttpUnit.

• Load and stress testing of database operations.

• Load and stress testing of EJB component interfaces.

• Load and stress testing of the web interface.

We've also discussed the desirability of designing applications so that central functionality can be tested against ordinary Java classes, rather than harder-to-test J2EE components.

Testing alone is not enough to ensure that code is bug free. Other useful strategies include using assertions in application code and introducing the practice of regular code reviews. Sound coding and design practices can do much to reduce the likelihood of bugs.

While the concepts discussed in this chapter apply whatever tools we use, I've concentrated on free, simple tools. These are ubiquitous and widely understood, but there are more sophisticated commercial testing tools available, especially for web applications, that are beyond the scope of this chapter.