This was not the book I expected, but it makes a lot of sense that it turned out this way. Cedric is like the Martin Luther of the testing world. I ranted about a lot of the same things in JUnit, especially for instance, the whole crazy TestDecorator business, but Cedric just blew the house down. TestNG, after JUnit, was like getting out of jail.
So it makes sense that this book is a kind of exhaustive compendium of testing approaches, and as such, it succeeds, in most ways. There are a few things that don't show up, for instance, there is discussion of container testing, but Shale is not mentioned (unit testing JSF is made much better by it, and JSF is part of JEE5 so it deserves attention). The section on testing XML was good, considering dom4j, XMLUnit, etc., but it ends too quickly. For instance, what about using XPath statements? or some schema tools?
Given that Cedric's partner in crime, of Bileblog fame, was aboard for this outing, rants were bound to ensue, and they are mostly useful and add value, if they are rather tame. The one about logging left me just totally perplexed. Logging is not good? It's made out to be even possibly harmful? Say what? On the other hand, the rants about JUnit are on target. Their rant about using test coverage as a badge of honor is right on the money.
They even go into Spring's test mechanisms, and do a good job with it. Then they skate through Guice to discuss some of the advantages of preventing the spread into XML. Now, the lead argument here is that not only does the metadata produce bloat, but it puts logic out of the grasp of refactoring tools (an argument Cedric has used v. dynamic languages).
In an age where computer books are usually long articles, this book goes through a dizzying range of subjects, and does so without resorting to the bland repetition of documentation that is already out there. I could only have wished for a greater emphasis on innovation. The reason is that this book I am afraid will scare people who really need to be brought into the fold. It's pathetic, really, but most teams are still either not testing or doing crazy things like writing a few tests after delivering the code. For people who have dug around trying to get a lot of the right things into their test diet, this is the best guide available right now.