- •contents
- •preface
- •acknowledgments
- •about this book
- •Special features
- •Best practices
- •Design patterns in action
- •Software directory
- •Roadmap
- •Part 1: JUnit distilled
- •Part 2: Testing strategies
- •Part 3: Testing components
- •Code
- •References
- •Author online
- •about the authors
- •about the title
- •about the cover illustration
- •JUnit jumpstart
- •1.1 Proving it works
- •1.2 Starting from scratch
- •1.3 Understanding unit testing frameworks
- •1.4 Setting up JUnit
- •1.5 Testing with JUnit
- •1.6 Summary
- •2.1 Exploring core JUnit
- •2.2 Launching tests with test runners
- •2.2.1 Selecting a test runner
- •2.2.2 Defining your own test runner
- •2.3 Composing tests with TestSuite
- •2.3.1 Running the automatic suite
- •2.3.2 Rolling your own test suite
- •2.4 Collecting parameters with TestResult
- •2.5 Observing results with TestListener
- •2.6 Working with TestCase
- •2.6.1 Managing resources with a fixture
- •2.6.2 Creating unit test methods
- •2.7 Stepping through TestCalculator
- •2.7.1 Creating a TestSuite
- •2.7.2 Creating a TestResult
- •2.7.3 Executing the test methods
- •2.7.4 Reviewing the full JUnit life cycle
- •2.8 Summary
- •3.1 Introducing the controller component
- •3.1.1 Designing the interfaces
- •3.1.2 Implementing the base classes
- •3.2 Let’s test it!
- •3.2.1 Testing the DefaultController
- •3.2.2 Adding a handler
- •3.2.3 Processing a request
- •3.2.4 Improving testProcessRequest
- •3.3 Testing exception-handling
- •3.3.1 Simulating exceptional conditions
- •3.3.2 Testing for exceptions
- •3.4 Setting up a project for testing
- •3.5 Summary
- •4.1 The need for unit tests
- •4.1.1 Allowing greater test coverage
- •4.1.2 Enabling teamwork
- •4.1.3 Preventing regression and limiting debugging
- •4.1.4 Enabling refactoring
- •4.1.5 Improving implementation design
- •4.1.6 Serving as developer documentation
- •4.1.7 Having fun
- •4.2 Different kinds of tests
- •4.2.1 The four flavors of software tests
- •4.2.2 The three flavors of unit tests
- •4.3 Determining how good tests are
- •4.3.1 Measuring test coverage
- •4.3.2 Generating test coverage reports
- •4.3.3 Testing interactions
- •4.4 Test-Driven Development
- •4.4.1 Tweaking the cycle
- •4.5 Testing in the development cycle
- •4.6 Summary
- •5.1 A day in the life
- •5.2 Running tests from Ant
- •5.2.1 Ant, indispensable Ant
- •5.2.2 Ant targets, projects, properties, and tasks
- •5.2.3 The javac task
- •5.2.4 The JUnit task
- •5.2.5 Putting Ant to the task
- •5.2.6 Pretty printing with JUnitReport
- •5.2.7 Automatically finding the tests to run
- •5.3 Running tests from Maven
- •5.3.2 Configuring Maven for a project
- •5.3.3 Executing JUnit tests with Maven
- •5.3.4 Handling dependent jars with Maven
- •5.4 Running tests from Eclipse
- •5.4.1 Creating an Eclipse project
- •5.4.2 Running JUnit tests in Eclipse
- •5.5 Summary
- •6.1 Introducing stubs
- •6.2 Practicing on an HTTP connection sample
- •6.2.1 Choosing a stubbing solution
- •6.2.2 Using Jetty as an embedded server
- •6.3 Stubbing the web server’s resources
- •6.3.1 Setting up the first stub test
- •6.3.2 Testing for failure conditions
- •6.3.3 Reviewing the first stub test
- •6.4 Stubbing the connection
- •6.4.1 Producing a custom URL protocol handler
- •6.4.2 Creating a JDK HttpURLConnection stub
- •6.4.3 Running the test
- •6.5 Summary
- •7.1 Introducing mock objects
- •7.2 Mock tasting: a simple example
- •7.3 Using mock objects as a refactoring technique
- •7.3.1 Easy refactoring
- •7.3.2 Allowing more flexible code
- •7.4 Practicing on an HTTP connection sample
- •7.4.1 Defining the mock object
- •7.4.2 Testing a sample method
- •7.4.3 Try #1: easy method refactoring technique
- •7.4.4 Try #2: refactoring by using a class factory
- •7.5 Using mocks as Trojan horses
- •7.6 Deciding when to use mock objects
- •7.7 Summary
- •8.1 The problem with unit-testing components
- •8.2 Testing components using mock objects
- •8.2.1 Testing the servlet sample using EasyMock
- •8.2.2 Pros and cons of using mock objects to test components
- •8.3 What are integration unit tests?
- •8.4 Introducing Cactus
- •8.5 Testing components using Cactus
- •8.5.1 Running Cactus tests
- •8.5.2 Executing the tests using Cactus/Jetty integration
- •8.6 How Cactus works
- •8.6.2 Stepping through a test
- •8.7 Summary
- •9.1 Presenting the Administration application
- •9.2 Writing servlet tests with Cactus
- •9.2.1 Designing the first test
- •9.2.2 Using Maven to run Cactus tests
- •9.2.3 Finishing the Cactus servlet tests
- •9.3 Testing servlets with mock objects
- •9.3.1 Writing a test using DynaMocks and DynaBeans
- •9.3.2 Finishing the DynaMock tests
- •9.4 Writing filter tests with Cactus
- •9.4.1 Testing the filter with a SELECT query
- •9.4.2 Testing the filter for other query types
- •9.4.3 Running the Cactus filter tests with Maven
- •9.5 When to use Cactus, and when to use mock objects
- •9.6 Summary
- •10.1 Revisiting the Administration application
- •10.2 What is JSP unit testing?
- •10.3 Unit-testing a JSP in isolation with Cactus
- •10.3.1 Executing a JSP with SQL results data
- •10.3.2 Writing the Cactus test
- •10.3.3 Executing Cactus JSP tests with Maven
- •10.4 Unit-testing taglibs with Cactus
- •10.4.1 Defining a custom tag
- •10.4.2 Testing the custom tag
- •10.5 Unit-testing taglibs with mock objects
- •10.5.1 Introducing MockMaker and installing its Eclipse plugin
- •10.5.2 Using MockMaker to generate mocks from classes
- •10.6 When to use mock objects and when to use Cactus
- •10.7 Summary
- •Unit-testing database applications
- •11.1 Introduction to unit-testing databases
- •11.2 Testing business logic in isolation from the database
- •11.2.1 Implementing a database access layer interface
- •11.2.2 Setting up a mock database interface layer
- •11.2.3 Mocking the database interface layer
- •11.3 Testing persistence code in isolation from the database
- •11.3.1 Testing the execute method
- •11.3.2 Using expectations to verify state
- •11.4 Writing database integration unit tests
- •11.4.1 Filling the requirements for database integration tests
- •11.4.2 Presetting database data
- •11.5 Running the Cactus test using Ant
- •11.5.1 Reviewing the project structure
- •11.5.2 Introducing the Cactus/Ant integration module
- •11.5.3 Creating the Ant build file step by step
- •11.5.4 Executing the Cactus tests
- •11.6 Tuning for build performance
- •11.6.2 Grouping tests in functional test suites
- •11.7.1 Choosing an approach
- •11.7.2 Applying continuous integration
- •11.8 Summary
- •Unit-testing EJBs
- •12.1 Defining a sample EJB application
- •12.2 Using a façade strategy
- •12.3 Unit-testing JNDI code using mock objects
- •12.4 Unit-testing session beans
- •12.4.1 Using the factory method strategy
- •12.4.2 Using the factory class strategy
- •12.4.3 Using the mock JNDI implementation strategy
- •12.5 Using mock objects to test message-driven beans
- •12.6 Using mock objects to test entity beans
- •12.7 Choosing the right mock-objects strategy
- •12.8 Using integration unit tests
- •12.9 Using JUnit and remote calls
- •12.9.1 Requirements for using JUnit directly
- •12.9.2 Packaging the Petstore application in an ear file
- •12.9.3 Performing automatic deployment and execution of tests
- •12.9.4 Writing a remote JUnit test for PetstoreEJB
- •12.9.5 Fixing JNDI names
- •12.9.6 Running the tests
- •12.10 Using Cactus
- •12.10.1 Writing an EJB unit test with Cactus
- •12.10.2 Project directory structure
- •12.10.3 Packaging the Cactus tests
- •12.10.4 Executing the Cactus tests
- •12.11 Summary
- •A.1 Getting the source code
- •A.2 Source code overview
- •A.3 External libraries
- •A.4 Jar versions
- •A.5 Directory structure conventions
- •B.1 Installing Eclipse
- •B.2 Setting up Eclipse projects from the sources
- •B.3 Running JUnit tests from Eclipse
- •B.4 Running Ant scripts from Eclipse
- •B.5 Running Cactus tests from Eclipse
- •references
- •index
references
Bibliography
Alur, Deepak, John Crupi, and Dan Malks. Core J2EE Patterns: Best Practices and Design Strategies. Upper Saddle River, NJ: Prentice Hall, 2001.
Beck, Kent. Smalltalk Best Practice Patterns. Upper Saddle River, NJ: Prentice Hall, 1996.
———. Extreme Programming Explained: Embrace Change. Reading, MA: Addison-Wesley, 1999.
———. Test Driven Development: By Example. Boston: Addison-Wesley, 2003.
Earles, John. “Frameworks! Make Room for Another Silver Bullet.” http:// www.cbd-hq.com/PDFs/cbdhq_000301je_frameworks.pdf.
Fowler, Martin. “The New Methodology.” http://www.martinfowler.com/ articles/newMethodology.html.
———. Patterns of Enterprise Application Architecture. Boston: Addison-Wesley, 2003.
———. Refactoring: Improving the Design of Existing Code. Reading, MA: Addison-Wesley, 1999.
Fowler, Martin, and Kendall Scott. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Reading, MA: Addison-Wesley, 2000.
Gamma, Erich, et al. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.
346
REFERENCES 347
Hatcher, Erik, and Steve Loughran. Java Development with Ant. Greenwich, CT: Manning, 2003. http://www.manning.com/hatcher/.
Jeffries, Ron. On the TestDrivenDevelopment mailing list: http://groups.yahoo.com/ group/testdrivendevelopment/message/3914.
Johnson, Ralph, and Brian Foote. “Designing Reusable Classes.” Journal of ObjectOriented Programming 1.5 (June/July 1988): 22–35. http://www.laputan.org/ drc/drc.html.
Marick, Brian. “How Many Bugs Do Regression Tests Find?” http://www.test- ingcraft.com/regression-test-bugs.html.
Potapov, Roman. “The Origin of Murphy’s Law.” http://www.geocities.com/murphylawsite/.
Rainsberger, J. B. “Refactoring: Replace Subclasses with Collaborators.” http:// www.diasparsoftware.com/articles/refactorings/replaceSubclassWithCollaborator.html.
Sisson, Derek. “Types of Tests.” http://www.philosophe.com/testing/tests.html.
Walls, Craig, and Norman Richards. XDoclet in Action. Greenwich, CT: Manning, 2003. http://books.manning.com/walls/.
Software directory
The software packages listed here are covered by the main text. Appendix A also provides a detailed list of the software packages and versions used by the book’s source code.
Table R.1 Software directory
Name |
Web site |
Quick description |
|
|
|
Ant |
http://ant.apache.org/ |
Build tool |
|
|
|
AspectJ |
http://eclipse.org/aspectj/ |
AOP framework |
|
|
|
Cactus |
http://jakarta.apache.org/cactus/ |
J2EE unit-testing frame- |
|
|
work |
|
|
|
Clover |
http://www.thecortex.net/clover/ |
Test coverage tool |
|
|
|
Commons BeanUtils |
http://jakarta.apache.org/commons/beanutils/ |
Reflection and intro- |
|
|
spection utilities for |
|
|
working on JavaBeans |
|
|
|
continued on next page
348 |
REFERENCES |
|
|
|
|
|
|
|
Table R.1 Software directory (continued) |
|
|
|
|
|
|
|
Name |
Web site |
Quick description |
|
|
|
|
|
Commons Collections |
http://jakarta.apache.org/commons/collections.html |
Complements the Java |
|
|
|
Collections API with |
|
|
|
other powerful data |
|
|
|
structures |
|
|
|
|
|
Commons Httpclient |
http://jakarta.apache.org/commons/httpclient/ |
HTTP client |
|
|
|
|
|
Commons Logging |
http://jakarta.apache.org/commons/logging.html |
Logging façade to other |
|
|
|
logging systems |
|
|
|
|
|
DbUnit |
http://www.dbunit.org/ |
Database unit-testing |
|
|
|
framework |
|
|
|
|
|
EasyMock |
http://easymock.org/ |
Mock objects genera- |
|
|
|
tion framework |
|
|
|
|
|
Eclipse |
http://www.eclipse.org/ |
Tools platform and Java |
|
|
|
IDE |
|
|
|
|
|
HttpUnit |
http://httpunit.sourceforge.net/ |
JUnit extension for test- |
|
|
|
ing web applications |
|
|
|
|
|
JBoss |
http://www.jboss.org/ |
J2EE container |
|
|
|
|
|
Jester |
http://jester.sourceforge.net/ |
Tool to verify quality of |
|
|
|
unit tests |
|
|
|
|
|
Jetty |
http://jetty.mortbay.org/ |
Servlet/JSP container |
|
|
|
|
|
JMeter |
http://jakarta.apache.org/jmeter/ |
Load-testing tool |
|
|
|
|
|
JSTL |
http://java.sun.com/products/jsp/jstl/ |
Standard JSP tag librar- |
|
|
|
ies |
|
|
|
|
|
JUnit |
http://junit.org/ |
Unit-testing framework |
|
|
|
|
|
JUnitBook |
http://sourceforge.net/projects/junitbook/ |
Source code for JUnit in |
|
|
|
Action |
|
|
|
|
|
JUnitPerf |
http://www.clarkware.com/software/JUnitPerf.html |
JUnit extension for mea- |
|
|
|
suring performance and |
|
|
|
scalability |
|
|
|
|
|
Maven |
http://maven.apache.org/ |
Project comprehension |
|
|
|
build tool |
|
|
|
|
|
MockObjects |
http://www.mockobjects.com/ |
Mock-objects frame- |
|
|
|
work |
|
|
|
|
continued on next page
|
|
REFERENCES |
|
349 |
|
Table R.1 Software directory (continued) |
|
|
|
|
|
|
|
|
|
||
|
|
|
|
||
Name |
Web site |
|
Quick description |
||
|
|
|
|
|
|
MockMaker plugin for |
http://www.mockmaker.org/ |
|
Static mock-objects |
|
|
Eclipse |
|
|
generation framework |
||
|
|
|
|
||
Taglibs |
http://jakarta.apache.org/taglibs/ |
|
Jakarta’s implementa- |
||
|
|
|
tion of JSTL |
|
|
|
|
|
|
||
Tomcat |
http://jakarta.apache.org/tomcat/ |
|
Servlet/JSP container |
||
|
|
|
|
||
xPetstore |
http://xpetstore.sf.net/ |
|
Sample Petstore appli- |
||
|
|
|
cation |
|
|
|
|
|
|
|
|
Software licenses
■The source code created for this book is provided under the Apache Software License (http://apache.org/LICENSE).
■JUnit is provided under the Common Public License (http://oss.soft- ware.ibm.com/developerworks/oss/license-cpl.html).