11 January 2005
I've just finished reading APress' upcoming publication of Test-Driven Development: A J2EE Example, written by Thomas Hammell (with Russell Gold and Tom Snyder). I'm left inspired to write unit tests for every upcoming task, and I regret many previous tasks for which I've never written tests. The authors do a great job of explaining the process and selling the whole test-driven method of development.
After convincing you to use TDD (Chapter 1), the book introduces the design of its example application (Chapter 2), and then gets into JUnit and its extensions. As you proceed through the chapters, you learn to use the extensions for testing in each tier (POJO, JSP/servlet, Swing, EJB, database). Most the high-level TDD concepts are explained in relation to plain objects, since these really are the easiest to test -- even a non-enterprise programmer could find the first couple chapters of this book very useful. The reasons and the basis of TDD were pretty familiar to me before reading this book.
The other tools introduced in subsequent chapters just made it easier to apply your unit testing capabilities to those tiers. The JUnit extensions and tools covered include HttpUnit, Cactus, MockObjects, Jemmy, DBUnit, and others. The capabilities of some of these extensions are pretty surprising, and the introduction to them all is quite valuable. Without having read this book, I wouldn't have even known some of this was possible.
The authors don't really introduce all the extensions in the beginning, so I found myself distracted by the thought, "This is great and all, but so much of my application is based on data, so it's not this simple." That was my reason for abandoning TDD (using Cactus) a couple years ago.
They do eventually get around to the useful extensions and methods for testing with and without the data tier. An earlier mention of these other tools would have put my mind at ease through those early chapters though. Up until the chapters actually covering the more complex tests, I had a nagging feeling that they were completely dancing around the complexity.
Back when I abandoned TDD in my previous work, it turns out I should have been using these other extensions (or just JUnit) where appropriate instead of trying to make Cactus do everything. I could have also learned to encapsulate my systems more completely had I been forced to look at them in distinct pieces through their unit tests. This is where I really wish I had this book to read 3 years ago. Regardless, the TDD fire is again ignited.
The final chapters of the book cover maintaining and refactoring your tests with your code, and transitioning an existing project (and workplace) to using TDD. I've immediately begun applying these new techniques to my current code at work. As one method suggested in the book, I'm just doing it. The tests exist in a parallel to the real code, so I can introduce this and prove it without having to disrupt the rest of the developers. Once I've worked out the details and benefits, I can introduce it to my fellow developers in the future.
I regard this book as an introduction to TDD and all the convincing you'll need to give it a try and even succeed. If you'd like to get started with TDD, get this book, download the tools it suggests, and use its examples as starting points to explore using TDD to design your own projects.