Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Java Tools for Extreme programming mastering open source tools including - Hightower R.

Hightower R. Java Tools for Extreme programming mastering open source tools including - Wiley publishing , 2002. - 417 p.
ISBN: 0-471-20708
Download (direct link): javatoolsforextremeprog2002.pdf
Previous << 1 .. 62 63 64 65 66 67 < 68 > 69 70 71 72 73 74 .. 159 >> Next

Summary
This chapter covered the basics of using JUnit (a framework for writing automated unit tests) to create automated testing for your project. We discussed some of the reasons why you would want to use automated testing. Unit-level testing shows that the code you just refactored did not break. Automated testing gives you confidence in your ability to refactor. Ant and JUnit together can automate the build, deploy, and test process, which is essential for continuous integration and refactoring. In addition, Ant allows you to create snazzy HTML reports on your project using the junit and junitreport tasks. This reports allows you to see the state of your project at a glance.
203
Chapter 8: Testing Container Services with Cactus
Overview
This chapter shows how to use Cactus for in-container testing, a vital concern of any XP/J2EE developer. To phrase it another way, this chapter attempts to answer the question, "How do I do unit tests on servlets and other J2EE components?" This chapter assumes familiarity with JUnit and J2EE components—especially servlets and JSPs.
Where to Get Cactus
Originally, Cactus was called J2EEUnit, a name that captured the intent of the framework nicely. However, Sun owns the J2EE trademark, so The Apache Software Foundation changed the framework's name to Cactus. Cactus was recently accepted as a top-level project under Jakarta, putting it on par with Ant,
Tomcat, and Struts. Simultaneously with this move, the package names for Cactus were changed from org.apache.commons.cactus to org.apache.cactus. Be sure to check the Cactus site for further developments.
Cactus is distributed under The Apache Software License, Version 1.1 and can be downloaded at:
? http://jakarta.apache.org/
Why In-Container Testing?
You need a framework like Cactus to test J2EE code. Why? Because of the special relationship that J2EE code—servlets, JSPs, EJBs, and so on—holds with its container. Naturally, unit testing focuses on units of program code. However, no code exists in a vacuum. Even the simplest program is dependent upon other units of code (any Java program, for instance, is dependent upon the JVM). One of the biggest challenges of unit testing is how to tease the unit apart from its context so that its behavior can be asserted independently.
Testing in Isolation: Mock Objects
A new unit testing technique termed Mock Objects or Endo-Testing was just beginning to make an appearance as we were writing this book. The idea behind Mock Object testing is to define "mock objects" that test cases can pass to the code being exercised. These mock objects take the place of domain objects and have dummy behavior that test cases can configure at runtime. A typical mock object interaction might go something like:
public void testFilter() {
mockFilter.setExpectedFilterCalls(1);
filterableObject.apply(mockFilter);
mockFilter.verify();
}
The verify() function would ensure that the expected calls to the filter's filter() function occurred.
Endo-testing solves the problem of code in context by providing an ultra-lightweight emulation of that context on a per-test basis. The Mock Object passed to code under test should encompass all of the state that the code needs to operate correctly.
Advantages to Mock Objects
Using Mock Objects refines the practice of unit testing by ensuring almost totally independent operation of the code under test. This provides a variety of advantages. Certain application states may be impossible, difficult, or time-consuming to reproduce. Mock Objects avoid this problem by keeping all of the "state" setUp in the Mock Object. Mock Objects also improve code design according to the authors of Endo-Testing: Unit Testing with Mock Objects (a paper presented by Tim Mackinnon, Steve Freeman, and Philip Craig at "extreme Programming and Flexible Processes in Software Engineering - XP2000"). An isolating unit test, "improves domain code by preserving encapsulation, reducing global dependencies, and clarifying the interactions between classes."
Disdvantages to Mock Objects
Mock Objects require some effort to design and implement. Mackinnon, et. al. point to this difficulty: "In some cases it can be hard to create Mock Objects to represent types in a complex external library. The most difficult aspect is usually the discovery of values and structures for parameters that are passed into the domain code." In the case of J2EE container services, the complexity and scope of the libraries can be very high. With time, as the Java community develops reusable mock libraries and perfects code generation tools for Mock Objects
204
this disadvantage will lessen. Several projects dedicated to theses goals already exist, however, at the time of this writing, most were in their early stages. One promising candidate is the Mock Objects project (http://www.mockobjects.com) an open source project hosted on SourceForge with contributors from the Cactus team.
Testing in Context: Integration Testing
Previous << 1 .. 62 63 64 65 66 67 < 68 > 69 70 71 72 73 74 .. 159 >> Next