JUnit, created by Kent Beck and Erich Gamma, is an open source framework for test-driven development in any Java-based code. JUnit automates unit testing and reduces the effort required to frequently test code while developing it. While there are lots of bits of documentation all over the place, there isn't a go-to-manual that serves as a quick reference for JUnit. This Pocket Guide meets the need, bringing together all the bits of hard to remember information, syntax, and rules for working with JUnit, as well as delivering the insight and sage advice that can only come from a technology's creator. Any programmer who has written, or is writing, Java Code will find this book valuable. Specifically it will appeal to programmers and developers of any level that use JUnit to do their unit testing in test-driven development under agile methodologies such as Extreme Programming (XP) [another Beck creation].
I can see using this book as a good reference but after reading I'm still going to have to search for a tutorial on writing a single test and how to use junit for the first time. A quick start section would have been useful. The examples feel more like code snippets rather than demonstrations.
This book has a TERRIBLY misleading title (causing a lowering of one star). This is NOT a pocket guide; it's a strong conceptual introduction. (Pocket guide implies immediate practical application through reference or "getting started" examples. This is neither.) So, why do I like it?
One can get started in test driven development (TDD) and use it beneficially WITHOUT really understanding deeper concepts (unfortunately, many do just that). That's where this book comes in. For example, while it does insist on testing first, it also includes the all-important WHY so you can better apply when helpful and in more helpful ways. This kind of TDD ensures that you think hard about the goal of code you are GOING to write (come on... you KNOW most of us just sit and start coding when we should first carefully define the goal). It's the software equivalent of "Start with the End in Mind" (nod to Mr. Covey's awesome classic, 7 Habits). THINK about what you want the results to be. Codify those results in small, simple tests (that will fail because the code isn't written) then write the business code.
Kent describes other great ways to use TDD concepts in things like contracting, and getting to know a library (again, codify what you think will/should happen with each call... then be SURE that actually does happen). There's much more. Any developer who cares about her/his craft should just be sure to have these concepts down solidly! I promise you'll be glad you are on the TDD learning path.