Chapter 18. JUnit and Cactus


Testing software is arguably the most important success factor in software engineering. No matter how elegant your architecture, no matter how compelling the features and user interface, and no matter how well a system is marketed, untested or poorly tested software is failure waiting to happen. Software that's tested is software that works, and working software is a pleasure, or at least a pleasant surprise.

Software testing has many dimensions. You can perform black box functional testing to determine whether an application operates correctly from an external standpoint without concern for the internal workings of the software. You can perform white box functional testing to validate the internal workings of the system at various levels. You can test the performance of software to determine how quickly it executes tasks under typical usage levels. You can perform load testing to determine the load threshold at which the system fails (or executes so slowly that it becomes effectively useless). You can perform user-acceptance testing, which tests software at an aggregate level to verify that a system performs acceptably to the target users, with metrics ranging from functional correctness to speed to interface aesthetics.

Software quality assurance is a subject of study in itself, and we won't presume to summarize it broadly in a single chapter. Instead, what we cover here is the subset of software testing referred to as unit testing, which attempts to verify the correct functional behavior of software at various levels of granularity. A "unit" may be a method on a class, an entire class, a component made up of several classes, or an entire subsystem of an architecture containing several components or classes. Strictly speaking, unit testing is typically performed during development on independent units of software, prior to these units being integrated into a complete application and passed along to other testing processes, like user interface functional testing, performance testing, and user-acceptance testing.

Why do we limit our discussion to unit testing? Besides the fact that more complete coverage of testing practices would take several additional chapters, we felt that unit testing tools and techniques provide the broadest applicability and have a necessary coupling with the enterprise framework being used to build systems.

Unit testing has broad applicability because it can be leveraged to provide elements of several of the other flavors of testing we discussed earlier. You can unit test software at a number of levels in your architecture, providing assurance of not only functional correctness but also a certain amount of integration testing. If a component uses a number of subcomponents or classes to execute its functions, testing the functionality of the component ends up testing the integration of these subelements to some degree. Unit tests can also be fashioned to be either black box tests, purposely ignorant of the internal workings of the unit being tested, or they can serve as white box tests, intentionally exercising and validating the internal workings of a unit.

Unit testing is also the tool most likely to be used by the audience we're targeting with this book: software engineers. Unit testing typically involves writing tests in the same programming environment as the software units being tested as well as understanding the workings of the software units at this level (object and component interfaces, data structures, and so on). Software engineers are uniquely qualified to write these unit tests. In part due to this fact, unit testing is a standard element in a number of modern software engineering processes, such as extreme programming (XP) and all of its many variations, feature-driven development (FDD), and the Unified Process (UP) defined in conjunction with the Unified Modeling Language (UML).

Finally, unit testing has a close coupling with the enterprise framework used to create applications, and since this book is focused on a particular enterprise framework (J2EE), it seemed appropriate to introduce unit testing tools aimed at this framework.

Please don't take our avoidance of performance testing, load testing, or UI functional testing as a statement that these forms of testing are less important than unit testing. These testing practices are equally important for creating successful software. But for the reasons given here, we felt that unit testing was most complementary to the rest of the material in this book and to the target readers of this book.



Java Enterprise in a Nutshell
Java Enterprise in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596101422
EAN: 2147483647
Year: 2004
Pages: 269

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net