< Day Day Up > Professional Java Tools for Extreme Programming ISBN:0764556177 by Richard Hightower, Warner Onstine et al Wrox Press © 2004 (733 pages) This is a practical, code-intensive guide to the tools that Enterprise Java developers need when using Extreme Programming methods It covers key tools used to automate complex parts of the XP process: application integration, testing, and deployment Table of Contents Professional Java Tools for Extreme Programming Introduction Part I - Key Concepts C hapter - Introduction to Extreme Programming C hapter - J2EE Deployment C oncepts C hapter - Storing and Managing C ode with C VS Part II - A utomated Building and Continuous Integration C hapter C hapter C hapter C hapter C hapter C hapter C hapter C hapter C hapter 10 11 12 - Ant Primer Building Java Applications with Ant Building J2EE Applications with Ant XDoclet Primer Building J2EE Web C omponents with Ant and XDoclet Building EJBs with Ant and XDoclet Building Struts Apps with Ant and XDoclet C reating C ustom Ant Tasks C reating XDoclet C ustom Tags and Templates Part III - A utomated Java Testing C hapter 13 - Unit Testing with JUnit C hapter 14 - Load Testing with JUnitPerf C hapter 15 - Defect Tracking with Bugzilla Part IV - A utomated J2EE Testing C hapter C hapter C hapter C hapter C hapter C hapter C hapter 16 17 18 19 20 21 22 - Functional Testing with HttpUnit Performance Testing with JMeter C actus Primer Testing Servlets and Filters with C actus JspTestC ases and Testing C ustom Tags with C actus Testing EJBs with C actus C ode C overage with jcoverage Part V - A utomated Swing Testing C hapter 23 - Swing Testing with Jemmy C hapter 24 - Swing Testing with jfcUnit C hapter 25 - Swing Testing with Abbot Part VI - Continuous Integration, Project Management, and IDEs C hapter 26 - Managing Projects with Maven C hapter 27 - Automating C ontinuous Integration with C ruiseC ontrol C hapter 28 - Automating C ontinuous Integration with AntHill Part VII - A PI Tag Reference C hapter C hapter C hapter C hapter C hapter C hapter 29 30 31 32 33 34 - Ant Tag Reference Ant API Reference JUnit API Reference C actus API Reference HttpUnit API Reference JUnitPerf API Reference Part VIII - A ppendix Appendix A - Example Applications Used in This Book Index List of Sidebars < Day Day Up > < Day Day Up > Back Cover The Extreme Programming (XP) methodology enables you to build and test enterprise systems quickly without sacrificing quality In the last few years, open source developers have created or significantly improved a host of Java XP tools, from XDoclet, Maven, AntHill, and Eclipse to Ant, JUnit, and C actus This practical, code-intensive guide shows you how to put these tools to work and capitalize on the benefits of Extreme Programming Using an example pet store application, our expert Java developers demonstrate how to harness the latest versions of Ant and XDoclet for automated building and continuous integration They then explain how to automate the testing process using JUnit, C actus, and other tools, and to enhance project management and continuous integration through Maven and AntHill Finally, they show you how to work with XP tools in the new Eclipse IDE C omplete with real-world advice on how to implement the principles and practices of effective developers, this book delivers everything you need to harness the power of Extreme Programming in your own projects What you will learn from this book How to automate the building of J2EE apps and components with Ant and XDoclet Techniques for automating Java testing JUnit Procedures for automating servlet, JSP, and other J2EE testing using C actus Ways to automate Swing testing with Jemmy, JFC Unit, and Abbot How to manage projects using Maven Techniques for automating continuous integration with AntHill and C ruise C ontrol How to harness plugins for JUnit, C actus, and Ant in the Eclipse IDE Ways to implement Extreme Programming best practices < Day Day Up > < Day Day Up > Professional Java Tools for Extreme Programming Ant, XDoclet, JUnit, Cactus, and Maven Richard Hightower Warner Onstine Paul Visan Damon Payne Joseph D Gradecki Kate Rhodes Robert Watkins Erik Meade Wiley Publishing, Inc Published by Wiley Publishing, Inc 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2004 by Wiley Publishing, Inc., Indianapolis, Indiana Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8700 Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-mail: permcoordinator@wiley.com Trademarks: Wiley, the Wiley Publishing logo, Wrox, the Wrox logo, the Wrox Programmer to Programmer logo and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc and/or its affiliates in the United States and other countries, and may not be used without written permission All other trademarks are the property of their respective owners Wiley Publishing, Inc is not associated with any product or vendor mentioned in this book Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose No warranty may be created or extended by sales representatives or written sales materials The advice and strategies contained herein may not be suitable for your situation You should consult with a professional where appropriate Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S at (800) 762-2974, outside the U.S at (317) 572-3993 or fax (317) 572-4002 Wiley also publishes its books in a variety of electronic formats Some content that appears in print may not be available in electronic books Library of Congress Card Number: Credits Authors Richard Hightower Warner Onstine Paul Visan Damon Payne Joseph D Gradecki Kate Rhodes Robert Watkins Erik Meade Executive Editor Robert Elliott Book Producer Ryan Publishing Group, Inc Copy Editors Liz Welch Linda Recktenwald Compositor Gina Rexrode Vice President & Executive Group Publisher Richard Swadley Vice President & Executive Publisher Robert Ipsen Vice President and Publisher Joseph B Wikert Executive Editorial Director Mary Bednarek Editorial Manager Kathryn A Malm About the Authors Richard Hightower Richard Hightower is Chief Mentor/Consultant for ArcMind, a full-service software development company Rick is a software engineer by training who specializes in software development tools and processes, and developing enterprise applications using J2EE, XML, UML, JDBC, SQL, and open source technologies Formerly he was the Senior Software Engineer for Java Architecture at Intel’s Enterprise Architecture Lab Rick is the co-author of Professional Jakarta Struts, and he contributed two chapters to the book Mastering Tomcat Rick has spoken at a variety of industry conferences and events, including JavaOne, TheServerSide.com Software Symposium JDJEdge, WebServicesEdge, and the Complete Programmer Network software symposiums Warner Onstine Warner Onstine is a founder and CTO of Interface Guru, a leading Web Usability firm where he consults on back-end technology issues with specific emphasis on how technology and usability work together to present the user with an easy-to-use interface Warner also runs his own custom development shop, Sandcast Software, which focuses on community and teamoriented software Warner got his first computer, a TI-99 4/A, when he was and almost immediately attempted to program a game in Basic on it, which did not work He stubbornly refuses to get rid of that machine though, along with his trusty NeXT Turbo MonoStation, upon which he got his first taste of Objective-C This eventually led to Java, skipping right over C++ His strong community background soon led him to open source, where he has had the chance to meet and interact with several incredible individuals from Jakarta and other open source communities This also has helped him to keep an open eye on the trends that will soon shape the new landscape—one of his specialties Another skill he has is in assisting companies with making the right choices at the right time, utilizing XP, in-depth knowledge of their subject area, and the currently available tools germane to their problem Warner is also a co-founder and President of the Tucson Java Users Group, which he helped form in 2001, which keeps him rather busy at times Previously, Warner worked at eBlox, Inc (a Web development company), Intalio, Inc (a bay-area Business Process Management Server company), and the University of Arizona Main Library on the Digital Library Team Paul Visan Paul Visan is an expert J2EE developer He serves as a Principal Software Engineer for eBlox, Inc, where he finds that open source tools are invaluable to his work Paul is a proud Romanian native, now living in the heart of Tucson Arizona He is a regular contributor to IBM’s developerWorks, for which he has written a series of tutorials on Java Web Services Paul would like to thank Andrew Barton, Nicholas Lesiecki, Tim Ryan, and Victoria McSherry for helping with this book Damon Payne Damon Payne currently works as the Microsoft Business Group manager for Centare Group, Ltd in Milwaukee, WI Damon is very passionate about open source technology in the Java and Microsoft NET worlds His other professional interests include Mobile development, data persistence patterns, and product development When not programming or speaking Damon enjoys raising his wonderful daughter, Brooke, home theater, and music Joseph D Gradecki Kate Rhodes Kate Rhodes is a self-taught programmer, serial entrepreneur, and occasional musician with a Japanese nickname and an unstoppable urge to learn new things, solve new problems, and write open source apps She’s got too many pets, too many projects, and too little time If she could afford an army of programming minions she’d have one She’s ranked better than most and worse than some She’s worked in impressive places you’ve possibly heard of and unimpressive places you’ve never heard of She’s done some stuff she’s very proud of and some she isn’t And so long as life keeps offering up interesting new challenges for her to learn from, she’s happy If you’re overcome with curiosity you can always see what Kate and her wife are up to at www.masukomi.org Robert Watkins Robert Watkins is a Brisbane, Australia-based software developer of nine years’ experience He’s been called a programmer, a software engineer, an architect, and a few other things (many unprintable), but mostly ignores the titles and does what he has to These days he is mostly working in J2EE and related technologies, and is a passionate advocate of agile development techniques When not working, he spends most of his time with his wife and twin children, and when he gets a chance, he takes time out to read Terry Pratchett novels Robert is also one of the developers on the CruiseControl project Erik Meade Erik Meade is an employee of Wells Fargo, who attended XPImmersionTwo, interviewed at XPImmersionThree, coached at XPImmersionFour, and out on the evenings of XPImmersionFive He is the edior of junit.org and an evangelist of JUnit, Ant, CruiseControl, HttpUnit, Tomcat, and open source in general He is also a contributor to JUnitPerf < Day Day Up > < Day Day Up > Introduction Overview This book describes techniques for implementing the Extreme Programming practices of automated testing and continuous integration using open source tools Let’s unpack that statement Automated testing and continuous integration are two of the twelve core practices of the Extreme Programming (XP) software development methodology Extreme Programming is a lightweight software development process that focuses on feedback, communication, simplicity, and courage The full XP process is summarized in Chapter 1; suffice it to say for now that it consists of common-sense development practices practiced religiously and in concert Two of these common-sense practices are testing and frequent integration Almost no software development shop would consider leaving these steps out of its process entirely—after all, a system has to be integrated to ship, and it must be tested to ensure that the customers accept the shipment Thanks to the dot-com shakeout, most of the shops that did skip these practices are now out of business Still, many software companies either struggle with implementing these processes, or acknowledge that they should be done but claim that “things are just too busy right now” to them This book explains and demonstrates the use of software tools to help put these valuable practices into place < Day Day Up > < Day Day Up > Why Spend So Much Time on the Tools? We focus on tools, ironically enough, because XP is a human-centric development philosophy It recognizes that the key challenges of writing software are human challenges-such as getting people to work together, helping programmers learn, and managing emotions Its four core values (communication, feedback, simplicity, and courage) are human values Most books published on XP so far have focused on the human issues: outlining the philosophy, spreading the ideology (Extreme Programming Explained was described by Kent Beck as a manifesto), and talking about the feeling of writing software By doing so, Kent Beck and the originators of XP have followed their own philosophy: Solve the most pressing problems first However, the current books not cover the technical details of implementing some of their practices That's where books like this one come in We will explain how to set up continuous integration and automated testing in a Java environment (specifically J2EE, although most of the tools apply generally) Technical detail will be addressed, and we will offer loads of examples to show the tools in action Specifically, we will cover how to use Abbot, Ant, AntHill, Bugzilla, Cactus, CruiseControl, CVS, Eclipse, HttpUnit, Jemmy, jfcUnit, JMeter, JUnit, Maven, and other tools to write automated tests and achieve continuous integration < Day Day Up > < Day Day Up > Who Should Read this Book Although this book speaks from an XP perspective, you need not practice XP to benefit from it Anyone who needs help automating testing and integration can benefit from the tools and practices outlined herein If you know nothing about Extreme Programming, you should probably read the rest of this Introduction, along with Chapter to get a sense of the practices covered in this book, both alone and in their XP context In particular the Introduction touches on the value of automated testing and continuous integration for all developers This book assumes you are at least a moderately experienced Java developer Because it covers the application of testing and integration tools to the J2EE platform, this book also expects familiarity with J2EE technologies and development practices Those who are not interested in J2EE applications will still find plenty of worthwhile material, because most of these tools can be applied to almost any Java (or, in the case of JMeter and HttpUnit, even non-Java) software project Developers who aren't familiar with J2EE but who want to apply these tools and techniques to a J2EE application may also want to pick up a comprehensive J2EE book like Expert One-on-One: J2EE Design and Development by Rod Johnson < Day Day Up > < Day Day Up > Why Open Source? It is hard to miss the growing prominence of open source development in software engineering Open source development tools offer compelling advantages over traditional tools—especially for XP development The advantages fall into two categories First, open source tools are practical Second, the open source philosophy is closely aligned with XP Open source tool offer several practical advantages: The price is right Open source software can almost always be obtained for free; all the tools we cover in this book can be downloaded at no cost from the Internet Free software means no immediate overhead for yourself or your company, which is always a benefit, but in this case not the major one The major benefit in the case of these tools is that their adoption will not be hampered by corporate red tape or management worried about buying into the latest fad Once you have downloaded JUnit, for example, and you’ve fallen in love with it and spread it to your team—speeding development and improving quality—no one will want to throw roadblocks in your way Starting the adoption of XP by asking for $7,500 worth of whizbang deployment tools might invite skepticism The tools are high quality Programmers use open source development tools every day Because improving the tool means improving their immediate situation, open source development tools often receive many contributions and bug fixes Improvement and features come fast and furious The tools are the standard Especially in the case of JUnit and Ant, the tools covered in this book are the standards in their field Countless open source projects use Ant, and JUnit (upon which several of the tools are based) was written by Kent Beck (the godfather of XP) and Erich Gamma (co-author of the OO classic Design Patterns: Elements of Reusable ObjectOriented Software) Synergy Between XP and Open Source Extreme Programming and open source development are closely aligned ideologically Both foster an open, giving style of collaborative development—they share a certain vibe, if you will Both philosophies acknowledge human weakness—no code is perfect, and the assistance of others in finding and fixing problems is gratefully acknowledged All open source code is commonly owned (as XP would have it) Many open source projects use and benefit from automated testing, which is especially important when code from a wide variety of sources must be integrated Both systems demand small, incremental releases Of course, both philosophies also focus heavily on the code—open source is founded on the premise that reading code is enjoyable, educational, and helpful The list could continue for quite a while By using open source tools (and by giving back to the open source community in the form of feedback, assistance, and code) you practice some of the values and processes that make XP great Read the Source If you are looking for more information than this book provides on any of the tools, the best place to start is the source code In addition to containing the Javadoc (another handy reference), the source code is the definitive authority on the tool’s behavior Open-source software exists because (in addition to liking free stuff) programmers value the ability to dig into the work of fellow coders By reading the source carefully, you can gain insight into how the program works, insight into the domain, and, if you are lucky, insight into the arcane art of programming itself If you are unlucky enough to encounter a bug while using the tool, having the source handy can help you determine where the bug lies < Day Day Up > < Day Day Up > Automated Testing: A Summary XP regards testing as central to the activity of software development To quote Dan Rawsthorne from the afterword of Extreme Programming Installed, “XP works because it is validation-centric rather than product-centric.” Testing software continuously validates that the software works and that it meets the customer’s requirements Automating the tests ensures that testing will in fact be continuous Without testing, a team is just guessing that its software meets those requirements XP cannot be done without automated testing, nor can development be done successfully without it All software projects need to satisfy the intended customer and to be free of defects Tests and Refactoring Another core XP practice is refactoring (changing existing code for simplicity, clarity, and/or feature addition) Refactoring cannot be accomplished without tests If you don’t practice XP, you may not be refactoring religiously Even the most stable or difficult-to-change projects require occasional modification To it right, programmers will have to change the existing design That’s where automated testing comes in Object-oriented programming (and, to a lesser extent, other programming styles) separates interface from implementation In theory, this means you can change the underlying logic behind a class or method, and dependent code will handle the change seamlessly Entire books have been written about this powerful abstraction However, if in practice the programmers are scared to change the underlying logic for fear of disturbing code that interacts with the interface, then this separation might as well not exist Comprehensive tests (run frequently) verify how the system should work and allow the underlying behavior to change freely Any problems introduced during a change are caught by the tests If Design A and Design B produce equivalent results when tested, the code can be migrated from one to the other freely With testing in place, programmers refactor with confidence, the code works, and the tests prove it Types of Automated Tests Unit tests are the most talked-about test in XP; however, they are only a part of the testing picture Unit tests cooperate with integration tests, functional tests, and auxiliary tests (performance tests, regression tests, and so on) to ensure that the system works totally Unit Tests: JUnit Unit tests are the first (and perhaps the most critical) line of tests in the XP repertoire Writing a unit test involves taking a unit of code and testing everything that could possibly break A unit test usually exercises all the methods in the public interface of a class Good unit tests not necessarily test every possible permutation of class behavior, nor they test ultra-simple methods (simple accessors come to mind); rather, they provide a common-sense verification that the code unit behaves as expected With this verification, the public interface gains meaning This approach makes changing unit behavior easier, and also provides a convenient (and verifiable) guide to the behavior of the unit Developers can consult a test to discover the intended use of a class or method In XP, unit tests become part of the cycle of everyday coding Ideally, programmers write tests before the code, and use the test as a guide to assist in implementation The authors both work in this mode, and we find ourselves unable to live without the guidance and corrective influence of unit tests After a unit is complete, the team adds the test to the project’s test suite This suite of unit tests runs multiple times per day, and all the tests always pass This sounds extreme; however, a 100 percent pass rate on unit tests is far more sane than the alternative: a piece of vital production code that does not work (If the code isn’t vital, why is it in the project?) Verifying each class builds a higher-quality system because it ensures that the building blocks work Unit tests also lead the way toward clean architecture If a developer writes a test three times for the same code in different locations, laziness and irritation will compel her to move the code to a separate location JUnit is a lightweight testing framework written by Erich Gamma and Kent Beck (one of the chief proponents of XP) The authors based its design on SUnit, a successful and popular unittesting framework written by Beck for Smalltalk The simplicity of the framework lends itself to rapid adoption and extension All the testing tools covered in this book (with the exception of JMeter, a GUI tool) interact with or extend the JUnit frame Integration/In-Container Tests: Cactus Unit testing covers Object X, but what about related Objects Y and Z, which together make up subsystem A? Unit tests are deliberately supposed to be isolated A good unit test verifies that no matter what chaos reigns in the system, at least this class functions as expected Several papers have been written (many can be found at http://www.junit.org) about strategies to avoid dependencies in unit tests (the core idea is to provide mock implementations of objects upon which the tested class depends) By all means, the unit tests should be made as independent as possible In their book Extreme Programming Installed, Jeffries et al have an interesting observation about errors that show up only in collaborations between classes; they say, “Our own experience is that we get very few of these errors We’re guessing here, that somehow our focus on testing up front is preventing them.” They go on to admit, “When they show up, such problems are difficult to find.” Good unit testing should indeed catch most errors, and the behavior of the entire system falls under the category of acceptance testing (also known as functional testing); however, a good test suite should verify subsystem behavior as well Integration testing occupies the gray area between unit and acceptance testing, providing sanity-check testing that all the code cooperates and that subtle differences between expectation and reality are precisely localized Integration tests may not always run at 100 percent (a dependency class may not be completed yet, for instance); however, their numbers should be quite high (in the 80 to 90 percent range) An important variety of integration tests is the in-container test The J2EE development model dictates components residing in a container Components rely on services provided by the container Interaction with those services needs to be verified Although some interactions can be successfully mocked-up, creating mocked implementations for all the services provided by a J2EE container would consume time and verify behavior imperfectly Some services, such as behaviors specified by deployment descriptors, could be very difficult to test, because container implementations differ The Cactus framework provides access to J2EE Web containers (which in turn usually provide access to other types of containers, such as EJB containers) By allowing tests to exercise code in the container, Cactus spares developers the chore of providing extensive or difficult mock-ups (they can use the real services, instead) This approach also provides an extra measure of feedback, because the code runs in an environment that is one step closer to its production habitat In the case of single objects that just interact with container services, in-container tests serve as quick-and-dirty unit tests Acceptance/Functional Tests: HttpUnit Functional testing ensures that the whole system behaves as expected These tests are also called acceptance tests because they verify for the customer that the system is complete (In other words, a Web site is not done until it can log in users, display products, and allow on-line ordering.) Functional tests are daunting in some ways (they are not an immediate productivity aid like unit tests), but they are crucial to measuring progress and catching any defects that slipped past the other tests or result from unimplemented/incomplete features Acceptance tests are written by the customer (the programmers may implement them) because they are for the customer Unit testing verifies for the programming team that the Foo class works correctly Acceptance tests verify for the customer (who may not know a Foo from a Bar) that their whole system works correctly Acceptance tests are less dependent upon specific implementation: For example, during an aggressive refactoring, the team may decide they no longer need a SubCategory object If so, the SubCategoryTest goes to execute in the Big Container in the Sky The team modifies the integration tests (if necessary) to account for the new system structure However, the functional tests remain unchanged, validating that the user’s experience of the catalog navigation system remains unchanged Functional tests not need to always run at 100 percent, but they should so before the software is released Functional tests often verify specific stories (an XP representation of a customer-requested feature) As such, they can track progress through a development cycle Each test that runs represents a finished feature Unfortunately but understandably, no one has written a universal acceptance-testing tool JUnit can work on just about any Java class, but an acceptance-testing tool must be tailored to the needs of a specific application For a number-crunching program, acceptance testing could be as easy as verifying inputs versus outputs For a data-entry application, a GUI recording and playback tool might be necessary We chose to cover HttpUnit, a testing API that allows programmatic calls to Web resources and inspection of the responses The framework cooperates with JUnit and exposes the underlying structure of an HTML page to allow easy verification of structural elements (The response to show_product.jsp returns a table with product prices.) It seemed a natural fit for the focus of this book, because J2EE is heavily concerned with Web components Acceptance testing the deeper components of J2EE might not even require a special framework because of the low level of presentation logic involved Performance Tests: JUnitPerf and JMeter Several types of testing exist besides basic verification of function parallel tests (verifies that a new system exactly like an old system), performance tests, validation tests (the system responds well to invalid input), and so on Of these, performance testing is perhaps the most widely applicable After all, the most functional system in the world won’t be worth a dime if end users give up on the software in disgust Client-side applications that perform poorly are trouble; server-side applications that drag are emergencies J2EE applications are usually hosted on servers handling anywhere from hundreds to thousands (and up!) of transactions per minute, so a small section of inefficient code can bring a system to its knees In this sort of environment, performance ranks with functional (or even unit) testing in its priority We will not be covering performance profiling tools (critical to solving performance issues); rather, we’ll discuss the testing tools used to uncover these problems early JUnitPerf does unit performance testing—it decorates existing JUnit tests so that fail if their running times exceed expectations Such tests support refactoring by verifying that performance-critical code remains within expected boundaries JMeter provides functional performance testing—measuring and graphing response times to requests sent to a remote server (Web, EJB, database, and so on) With JMeter, customers can write acceptance tests like, “The Web server will maintain a three second or better response time to requests with a 150 user simultaneous load.” < Day Day Up > < Day Day Up > Index P P4 component (CruiseControl), 498 P4BootStrapper component (CruiseControl), 498–499 package element (Maven), 465 package mapper (Ant), 64 package target (Ant), 70 building WAR files with (Model Hello World), 96–97 Hello World application project, 78 Hello World model project, 72 in master buildfiles, 124–125 outputting multiple JAR files (Model Hello World), 117 pet store example, 127 PageContextWrapper class (Cactus), 631 pair programming (XP practice), 7–8 parallel task (Ant), 62–63 parameters, setting, 308–309 path coverage, 411 path pathelements (Ant), 44 Path tag (Ant), 530 pathelements (Ant), 44–46 location, 44 path, 44 PathTokenizer class (Ant), 569–570 patternset element (Ant), 555 patternsets (Ant), 49–50 Pause component (CruiseControl), 499–500 performance monitoring See JMeter performance testing See JMeter pet store example, 676–677 AntHill, 525–526 baseline version build system, 683–687 database schema, 680 dbmodel classes, 679 dbmodel package listings, 695–701 JSPs (listings), 707–711 model classes, 678–679 model package listings, 692–695 populating database (with Ant), 687–691 targets, 686–687 test package listings, 701–706 Web.xml listings, 707–711 Web interface, 681–683 business need, 386 custom tag, writing, 388–390 EJB, adding, 243 Category class, 251 CategoryDB class, 251 CategorySystem class, 250–251 deploying, 254–260 product entity bean, 397–401 product entity bean, adding, 244–246 public interface tests, 251–254 test buildfile, 260–262 test cases, 246–250 test output, 262 testing, 401–408 enterprise application deployment, 126–128 JSPs, examining, 386 JUnit tests, 234–235 buildfile, 239–242 CategorySystemTest, 235–236 CategoryTest, 236–237 output, 242 public interface tests, 237–238 Maven building the project, 484–485 custom deployment options, 485 defining dependencies, 481–482 deployment, 486 directory structure, 480–481 Eclipse plug-in, 484 project descriptors, 482–484 Web site, 486–487 tag loop, 387–388 TestCase, writing, 386–387 testing with JMeter form entry testing, 327–334 navigation testing, 322–327 RDBMS testing, 334–335 XSLT prototype, 335–337 test analysis, 341 test results, 339–340 testing with JMeter, 338 planning game (XP practice), plug-ins (Maven) declaring as dependencies, 461–462 Eclipse, 484 goals, 459–460, 469–470 installing, 461 multiproject, 478 properties, 470 troubleshooting, 462 POM (Project Object Model), 462–465 pomVersion element (Maven), 464 populating databases, pet store example, 687–691 portletdoclet task, 141 PostMethodWebRequest class (HttpUnit), 644–645 practices of XP, 4–5 40-hour weeks, 8–9 coding standards, collective ownership, continuous integration, 6–7 metaphor, on-site customers, pair programming, 7–8 planning game, refactoring, simple design, small releases, testing, 5–6 preGoal element (Maven), 473–474 prepare target (Ant), 70, 73 < present> selector (Ant), 48 preset queries (Bugzilla), 293 productLink tag example, 376–377 products (Bugzilla), 285–286 ProductTest example, 401–408 Project class (Ant), 570–574, 582–583 project descriptors (Maven) creating, 476–478 pet store example, 482–484 project element (Maven), 464–465 project management See Maven project properties file (Maven), 467 project tag (Ant), 528 < project> tag (CruiseControl), 491 ProjectHelper class (Ant), 574–575 project.properties file (Maven), 478 projects (Ant), 39–40 project.xml file example, 462–464 properties Ant, 42–43 accessing, 203–204 passing, 51 setting, 43 with XDoclet, 154 Maven, 470, 471–472 properties element (Maven), 466 property task (Ant), 534–535 PropertyTagsHandler (XDoclet), 214–215 Protectable interface (JUnit), 589 public interface tests, 251–252 publish target (Ant), 40 publisher components (CruiseControl), 501–502 PutMethodWebRequest class (HttpUnit), 645–646 PVCS component (CruiseControl), 498 < Day Day Up > < Day Day Up > Index Q quality, XP and, queries (Bugzilla), 291–293 quiet period (CruiseControl), 492 Quilt, 409 < Day Day Up > < Day Day Up > Index R race coverage, 411 RandomTimer class (JUnitPerf), 669-670 reactor plug-in (Maven), 478 redirector servlet, calling, 353 redirectors, 346, 361 refactoring, 7, 221-222, 409 reflection, 247 regexp mapper (Ant), 64 registration system example (Struts) Action object, 188-189 ActionForm, 188-189 compiling, 195 configuration file, 190-191 register page, 193-194 running, 195 setup, 194-195 success and failure pages, 192-193 web.xml file, 191-192 relational operator coverage, 411 relations (EJBs), 176-177 repeat tag (JSP), testing, 378-379 RepeatedTest class (JUnit), 602 replace task (Ant), 548-549 report task (Ant), 412 reporters (JMeter), 322 reports jcoverage, 409 branch coverage, 418-419 statement coverage, 417 JUnit detailed report, 230-231 output directory, 242 publishing to Web sites, 232 summary report, 230 reports element (Maven), 465, 478 repositories See code repositories repository element (Maven), 465, 476 request object (Cactus), 354 RequestDispatcherWrapper class (Cactus), 631-632 Resin, 126 resources element (Maven), 466 response inspection (HttpUnit), 300-301 feedback form example, 307-309 login testing example, 301-303 sales report page example, 303-309 accessing tables, 305-306 HTML generated, 304-305 test code, 306-307 response object (Cactus), 354 results collection (Cactus), 356-357 RobotTestHelper class (jfcUnit), 438 RuntimeConfigurable class (Ant), 575-576 < Day Day Up > < Day Day Up > Index S SameTimeAnnouncementPublisher component (CruiseControl), 502 < schedule> element (CruiseControl), 492 scheduling builds (AntHill), 523 scope of iteration, determining, scopes, tag handlers, 375 SCP component (CruiseControl), 502 scripting variables, verifying, 385 ScriptTestSuite function (Abbot), 451 security, Bugzilla, 293 selectors (Ant), 46 containers, 49 < contains>, 46 < containsregexp>, 48 < date>, 46-47 < depend>, 47 < depth>, 47 < different>, 47 < filename>, 47-48 < present>, 48 < size>, 48 < type>, 48 selectTab() method (jfcUnit), 440 servers, CVS adding files, 27-30 administration, 33-34 checking out code, 27 connecting to, 26-27 creating branches, 31-33 local, 24-25 locking files, 31 recovering files, 34-35 removing files, 33 updating modules, 30-31 ServiceDefinition class (Cactus), 616 ServiceEnumeration class (Cactus), 616 servlet mappings, 17 ServletConfigWrapper class (Cactus, 632-633 ServletContextWrapper class (Cactus), 633 ServletRedirector (Cactus), mapping, 361 servlets, testing (Cactus), 361-365 ServletTestCase class (Cactus), 351, 361, 616-619 ServletTestRequest class (Cactus), 620-621 ServletURL class (Cactus), 621-622 session beans creating with XDoclet, 180-181 Hello World Model project, 107-110, 114 session information, tracking (JMeter), 326-327 setProps target (Ant), 70, 71-72 setter methods, testing, 402 setUp() method (Cactus), 355-356 shadow proxy bean (Hello World Model project), 110-113 shared libraries, creating buildfiles for, 70 shortDescription element (Maven), 465, 476 simple design (XP practice), simplicity (XP value), 2, siteAddress/siteDirectory element (Maven), 465, 476 < size> selector (Ant), 48 small releases (XP practice), source code instrumentation, 410 source control system components (CruiseControl), 498 sourceDirectory element (Maven), 466, 477 sourceModifications element (Maven), 466, 478 spider example (HttpUnit testing), 312-314 sql task (Ant), 544-545 src directory (Maven), 467-468 SSL (Secure Sockets Layer), HttpUnit testing ability, 311 staging targets (Ant), 40 StarTeam component (CruiseControl), 498 StarTeamBootStrapper component (CruiseControl), 498-499 startup classes See main classes statement coverage, 411, 417 sticky options (CVS), 29 sticky tags (CVS), 29 Strachan, James, 472 Struts installing, 187-188 overview, 187-188 registration system example Action object, 189-190 ActionForm, 188-189 compiling, 195 configuration file, 190-191 register page, 193-194 running, 195 setup, 194-195 success and failure pages, 192-193 web.xml file, 191-192 with XDoclet, 195-198 @ struts.action-forward tag (XDoclet), 196-197 @ struts.action tag (XDoclet), 196-197 @ struts.form tag (XDoclet), 195-196 @ struts.validator tag (XDoclet), 196 Student bean EJB example (XDoclet), 177-180 SubmitButton class (HttpUnit), 646 subprojects, calling (Maven), 478-479 subtasks (XDoclet), 141-142 SVN component (CruiseControl), 498 SVNBootStrapper component (CruiseControl), 498-499 Swing testing, 425-426 Abbot, 447-448 advantages, 455 defining components, 451 defining launch arguments, 451 dialog test example, 453-454 integrating tests, 450-451 ScriptTestSuite function, 451 table test example, 452-453 test suite, creating, 454-455 Costello, 447-448 adding assertions, 453 cleaning up results, 454 editor frame, 449 key modifiers, 450 recording tests, 448-450 Robot mode, 449 STDOUT errors, 450 Jemmy button test example, 427-429 dialog test example, 431-433 downloading, 425 JFrameOperator, 426 non-blocking variants, 432 primary frames, finding, 426-427 selecting tabs, 428 supressing output, 436 table test example, 429-431 timeouts, 433-436 jfcUnit, 437 advantages, 445-446 button test example, 440-441 ComponentFinder class, 439 dialog test example, 444-445 downloading, 438 Finder class, 438 JFCTestCase class, 438 RobotTestHelper class, 438 selecting tabs, 440 table test example, 442-443 TestHelper class, 438-439 system testing See JMeter < Day Day Up > < Day Day Up > Index T TableCell class (HttpUnit), 646-647 tables, accessing with HttpUnit, 305-306 tag handlers, 373 nested tags, 381-384 scopes, 375 tag libraries (Jelly), 472-473 tag library descriptor testing, 384-385 TagData objects, 384 TagExtraInfo class, 384 taglibs (XDoclet), 154-157 tags Javadoc, 132-133 XDoclet custom, 214-215 @ ejb.bean, 172-173 @ ejb.create-method, 175 @ ejb.finder, 173-174 @ ejb.home, 173 @ ejb.interface, 173 @ ejb.interface-method, 175-176 @ ejb.persistence, 174-175 @ ejb.persistence-field, 175 @ ejb.pk, 173 @ ejb.relation, 176-177 @ ejb.transaction, 177 @ struts.action, 196-197 @ struts.action-forward, 196-197 @ struts.form, 195-196 @ struts.validator, 196 webdoclet, 150-152 Target Class (Ant), 576-577 target directory (Maven), 468 Target tag (Ant), 529-530 targets (Ant), 39-40, 200 all, 40 clean, 40 compile, 40 conditional, 50-52 default, setting, 71 deploy, 40 docs/javadocs, 40 fetch, 40 Hello World application project, 76 Hello World model project, 70-73 init, 40 init-debug, 40 init-release, 40 link/jar, 40 main, 40 naming, 39-40 pet store example, 686-687 publish, 40 staging, 40 standard, 40 test, 40 Task class (Ant), 201-203, 578-579 TaskAdapter class (Ant), 580 taskdef task (Ant), 535 tasks, 39-40 adding to Maven projects, 473-474 BuildNumber, 62 check, 412 Chmod, 62 custom accessing properties, 203-204 < classpath> element, 204 example buildfile, 208-211 execute() method, 204-205 nested elements, 205-208 Task class, 201-203 TDSS task example, 200-201 cvs, 62 < echo>, 493 ejbdoclet, 136-140, 141 hibernatedoclet, 141 instrument, 412 JAR, 63 jcoverage as, 411-416 jdodoclet, 141 jmxdoclet, 141 jtestrun, 412 merge, 412 mockdoclet, 141 parallel, 62-63 portletdoclet, 141 report, 412 webdoclet, 141 with Eclipse, 157-167 generating deployment descriptors, 152-154 Struts application, 197-198 taglibs, 154-157 tags, 150-152 tearDown() method (Cactus), 355-356 templates (XDoclet), 133, 142-143 custom template example, 217-220 simple template example, 216-217 test cases (JUnit), 223 defining classes, 225 defining tests, 226-227 HashMapTest example, 223-228 overriding setUp(), 225 VectorTest, 223 test data, creating with Ant, 687-691 test fixtures, 223, 590 Test Interface (JUnit), 589 test suites (JUnit), 223, 227-228 test targets (Ant), 40 JUnit integration, 229-230 JUnit test project, 241-242 TestCase class (JUnit), 589-593 TestCases (Cactus) FilterTestCase, 351 JspTestCase, 351 server-side execution, 355-356 server-side setup, 353-354 ServletTestCase, 351 TestDecorator class (JUnit), 603-604 TestFailure class (JUnit), 594 TestHelper class (jfcUnit), 438-439 testing See also automated testing functional, 297-298 integration, 344 advantages, 344-345 disadvantages, 345 as XP practice, 5-6 testing controllers (JMeter), 321 TestListener interface (JUnit), 593-594 TestPlans (JMeter), 320-321 TestResult class (JUnit), 594-597 TestSetup class (JUnit), 604-605 TestSuite class (JUnit), 597-600 testXXX() method (Cactus), 356 ThreadBarrier class (JUnitPerf), 670 ThreadedTest class (JUnitPerf), 671 ThreadedTestGroup class (JUnitPerf), 671-672 ThreadGroups (JMeter), 320 controllers, 321-322 listeners, 322 setting up (pet store example), 322-323 threads (JMeter), 321 timed tests (JUnitPerf), 264 decorating tests with, 264, 275-276 Loop test case creating tests, 264-268 running, 269-271 test data, 268 TimedTest class (JUnitPerf), 672-674 timeouts (Jemmy), 433-436 timers (JMeter), 321, 325 Tomcat, 126, 486 touch task (Ant), 538-539 tracer bullets, 319 Tstamp tag (Ant), 531 Turbine, 457 type element (Maven), 466 < type> selector (Ant), 48 < Day Day Up > < Day Day Up > Index U UML (Unified Modeling Language), un-assembled enterprise beans, 17 Unified Modeling Language See UML unit testing See also JUnit Mock Objects, 343-344 necessity of, 221-222 unitTest element (Maven), 466 unitTestSourceDirectory element (Maven), 466, 477 unjar task (Ant), 548 UnknownElement class (Ant), 580-581 unpackage mapper (Ant), 64 unwar task (Ant), 548 unzip task (Ant), 548 updating modules (CVS repositories), 30-31 urban{code} example project (AntHill), 514-515 url element (Maven), 465, 466, 476 < Day Day Up > < Day Day Up > Index V Validate tag library (Jelly), 473 VectorTest test case, 223 test results, 231-232 version element (Maven), 464 versioning benefits of, 23-24 code repositories, 24 versions/version element (Maven), 465, 476 visualizers (JMeter), 322, 326-327 voting (Bugzilla), 295 VSS component (CruiseControl), 498 VSSBootStrapper component (CruiseControl), 498-499 VSSJournal component (CruiseControl), 498 < Day Day Up > < Day Day Up > Index W WAR files (Web ARchive files), 16 applets, including (Ant), 103-104 building, with package targets (Model Hello World), 96-97 deploying (pet store example), 127-128 EJB deployment, 259-260 war task (Ant), 96, 546-547 Web applications See also pet store example components, 15 deployment descriptors, 15-16 directory structure, 16-17, 88-89 public interface tests, 251-252 Web ARchive files See WAR files Web browsers, JAR file support, 14-15 WebClient class (HttpUnit), 299-300, 647-651 WebConversation class (HttpUnit), 651 WebCVS, 36 webdoclet task, 141 with Eclipse, 157-167 generating deployment descriptors, 152-154 Struts application, 197-198 taglibs, 154-157 tags, 150-152 WebForm class (HttpUnit), 308-309, 651-654 WebLink class (HttpUnit), 654-655 WebRequest class Cactus, 351-352, 622-625 HttpUnit, 300, 655-659 WebResponse class Cactus, 305-306, 357-358, 625-626 HttpUnit, 300, 358-359, 637, 659-662 WebTable class (HttpUnit), 305-306, 662-663 WebTestResult class (Cactus), 626-627 web.xml files (Struts), 191-192 WinCVS, 36 Windows, CVS on, 35 WorkBench node (JMeter), 321 < Day Day Up > < Day Day Up > Index X XDoclet See also Ant architecture, 213–214 configuring, 134–136 custom tags, 214–215 ejbdoclet task, 136–140, 141 EJBs, creating Ant build script, 182–184 database setup, 169–170 entity beans, 170–176 relations, 176–177 session beans, 180–181 Student bean example, 177–180 filters (Ant), 154 hibernatedoclet task, 141 init-params (Ant), 154 installing, 134 Javadoc, 131–133 jdodoclet task, 141 jmxdoclet task, 141 merge points, 143 mockdoclet task, 141 portletdoclet task, 141 properties (Ant), 154 PropertyTagsHandler, 214–215 sample buildfile, 140–141 simple servlet example, 145–150 with Struts, 195–198 subtasks, 141–142 support, 133–134 templates, 133, 142–143 custom template example, 217–220 simple template example, 216–217 webdoclet task, 141 with Eclipse, 157–167 generating deployment descriptors, 152–154 taglibs, 154–157 tags, 150–152 XML tag, 528 XmlLogger (Ant), 61–62 XmlLogger class (Ant), 581–582 XP (Extreme Programming) adopting, 9–10 overview, 1–2 practices, 4–5 40-hour weeks, 8–9 coding standards, collective ownership, continuous integration, 6–7 metaphor, on-site customers, pair programming, 7–8 planning game, refactoring, simple design, small releases, testing, 5–6 principles of, 3–5 values communication, courage, feedback, 2, simplicity, 2, XSLT pet store prototype, 335–337 testing with JMeter creating test, 338 execution, 338 listeners, 338 results, 339–340 test analysis, 341 XSLT transform engine, 229 XSLTLogPublisher component (CruiseControl), 502 < Day Day Up > < Day Day Up > Index Z zip task (Ant), 547 zipfileset element (Ant), 556 < Day Day Up > < Day Day Up > List of Sidebars Introduction Read the Source Restart! Chapter 1: Introduction to Extreme Programming If the Code Smells, Refactor It UML and CASE tools Chapter 3: Storing and Managing Code with CVS Where to Get Concurrent Versions System (CVS) Chapter 4: Ant Primer Where To Get Ant What Is Your Favorite IDE? Chapter 13: Unit Testing with JUnit Where to Get JUnit System.out.println Is Not Enough Security and Authentication IDEs Support JUnit and Ant Chapter 14: Load Testing with JUnitPerf Where To Get JUnitPerf Real Test Chapter 15: Defect Tracking with Bugzilla Where to Get Bugzilla Chapter 16: Functional Testing with HttpUnit Where to Get HttpUnit HttpUnit vs Cactus Is This a Valid Test? Errors or Failures? Chapter 17: Performance Testing with JMeter Where To Get JMeter Being a Hero Is No fun Chapter 18: Cactus Primer Where to Get Cactus A Real-World example Cactus vs HttpUnit A Possible Trap Chapter 20: JspTestCases and Testing Custom Tags with Cactus Then How Can I Test My JSPs? Chapter 21: Testing EJBs with Cactus Security and Authentication IDEs support JUnit and Ant Chapter 22: Code Coverage with jcoverage Where to Get jcoverage Chapter 23: Swing Testing with Jemmy Where to Get Jemmy Chapter 24: Swing Testing with jfcUnit Where to Get jfcUnit Chapter 26: Managing Projects with Maven Where to Get Maven Where to Get Jelly Chapter 27: Automating Continuous Integration with CruiseControl Where to Get CruiseControl What Do Your Build Scripts Do? Timing Difficulties Use “Antscript” by Preference Keeping Track of Your Builds What Sort of Information Do You Want in Your Builds? Where's the Address Book? Cruise RemoteControl Getting the Build Label Resource Management Chapter 28: Automating Continuous Integration with AntHill Where to Get AntHill Appendix A: Example Applications Used in This Book Where To Get the Example Applications Database IDENTITY < Day Day Up > ... IDE Ways to implement Extreme Programming best practices < Day Day Up > < Day Day Up > Professional Java Tools for Extreme Programming Ant, XDoclet, JUnit, Cactus, and Maven Richard Hightower... significantly improved a host of Java XP tools, from XDoclet, Maven, AntHill, and Eclipse to Ant, JUnit, and C actus This practical, code-intensive guide shows you how to put these tools to work and. .. development tools often receive many contributions and bug fixes Improvement and features come fast and furious The tools are the standard Especially in the case of JUnit and Ant, the tools covered