Previous    Next

Testing J2EE apps

Overview

In we saw that decisions made early in the project lifecycle can determine a project's success or failure. Testing is another critical area in which we must develop a strategy and establish good practices from the outset of a project. Testing is often treated as an uninteresting activity that can be undertaken after development is largely complete. No one seriously believes that this is a good approach, but it's the usual outcome when there's no coherent testing strategy from project commencement. Most developers are aware of the many problems such reluctant testing brings, such as the fact that the cost of rectifying bugs escalates rapidly, the longer they take to emerge. In this chapter we consider a positive approach to testing. We'll see that testing is something we should do, not just out of fear of the consequences of not doing it, but because it can be used to improve the way we develop code. If we view testing as an integral part of our development process, we can not only raise the quality of our apps and make them much easier to maintain, but also increase productivity.

Testing enterprise apps poses many challenges:

• Enterprise apps usually depend on resources such as databases, which will need to be considered in any testing strategy.

• Testing web apps can be difficult. They don't expose simple Java interfaces that we can test, and unit testing is complicated by the dependence of web tier components on a web container.
• Testing distributed apps is difficult. It may require numerous machines and may be hard to simulate some causes of failure.
• J2EE components - especially EJBs - are heavily dependent on server infrastructure.
• A J2EE app may involve many architectural layers. We must test that each layer works correctly, as well as perform acceptance testing of the app as a whole.

In this chapter, we discuss these challenges and approaches to meet them. We'll look at:

• Testing goals and concepts.

• The Extreme Programming (XP) approach to testing, which is based on test-first development. XP elevates testing into the centerpiece of the development process. Tests are regarded as essential app deliverables. Tests are written before code and always kept up to date. Whether or not we consider adopting XP overall, this is a very effective approach. While all good programmers test their code often, there are real advantages from proceeding from an ad hoc approach to a more formal approach, in which tests are documented and easily repeatable.
• The JUnit testing framework, which provides a good basis for our testing strategy. JUnit is a simple but highly effective tool, which is very easy to learn, and which enables tests to be written with a minimum of hassle.
• The Cactus J2EE testing framework, which builds on JUnit to enable J2EE components such as EJBs to be tested within an app server.
• Techniques for testing web interfaces.
• The importance of automating tests, so that all tests for an app can be run in a single operation. We'll see how the Ant build tool can be used to automate JUnit tests.
• Complementary approaches to testing, such as assertions, which we can use as part of an integrated QA strategy.

Previous    Next