This book does a great job of introducing TestNG, showing how to use its features to set up tests for code that (inevitably) depends on various JEE APIs, and how to perform different kinds of testing (browser, database, performance etc).

There are some claims that I found hard to follow: For example, the authors advise against using mock objects to stub out external classes, then later state that servlets are hard to test outside of a container because they depend on a few external classes -- never mind that these are simple to mock out, and that the Spring testing library (which they mention elsewhere) even provides mock implementations for these classes. There are also some minor factual errors that should have been caught in the reviewing process (e.g. contrary to what is claimed, annotations can be inherited).

Then there is the "Digressions" chapter, which, as others have pointed out, should have been posted as a series of blog posts. Instead, there are some areas where more detail could have been provided. e.g. on how groups work in TestNG, or the exact semantics of the parallel test execution options. Now that TestNG has been out for a while and gained a lot of popularity, I'm sure there is also a lot more information on common problems that could be included in a future 2nd edition!

This book is not really about testng. it's more about the author's opinions about testing, which are for the most part valid, but I bought this book mostly for the testng part, and I guess I'll have to wait to find something more targeted towards teaching just testng.

Very nicely written keeping real world requirements in mind. Could have had some more examples.

At last a book that deals with testing applications (in java) that seems to be written by author's who have worked with real life, non trivial projects(TDD with adding two money objects together, anyone?).
This book describes using TestNG along with some advanced TestNG concepts and goes on to show how to use the framework to test out JEE projects. There are also chapters showing the developer how to integrate TestNG with other frameworks (like spring, DBUnit, jwebunit etc) which is useful as this is perhaps the only place where JUnit is better than TestNG. Inspite of the fact that TestNG documentation is pretty good, this book is worthwile buying (even if you use JUnit as your testing tool of choice).
There is useful coding and refactoring advice along the way(also a commentary on TDD), and a miscellaneous chapter of sorts which seems to have been written by Hani and edited by Cedric to remove all profanities!.
I do hope the author's expand the testing enterprise application bits to cover more testing scenarios and examples in later additions.

College-level libraries strong in Java programming guides need NEXT GENERATION JAVA TESTING: unlike many Java programmer's guides, it provides a pragmatic discussion for Java developers interested in building stronger code for applications, and packs in chapters discussing testing methods, tradeoffs associated with testing, applications of testing theory and rules, analysis of partial failures and remote invocation, and more. In-depth and extensive code examples throughout also differentiate NEXT GENERATION JAVA TESTING from competitors, making it a top recommendation.

Diane C. Donovan
California Bookwatch

"Next Generation Java Testing" has a subtitle: "TestNG and Advanced Concepts." This isn't surprising given the creator of TestNG is an author, but is important to realize. It starts with 6.5 pages on why TestNG is better than JUnit 3.8. Then only two paragraphs on JUnit 4. This has been a pet peeve of mine for some time. It's like comparing the current version of C# to Java 1.3 and then saying Java is worse because it doesn't have generics.

I liked the code snippets in the TestNG sections as they focused on relevant pieces. The examples were to the point. Especially the performance and J2EE sections. I liked the concepts described in chapter 2 (over 100 pages.)

The authors describe open source libraries that integrate with TestNG. I liked this coverage although JMock could have used a code example for comparison (easyMock had one.) Ant targets were provided for the code coverage examples.

Chapter seven is titled "digressions." Some quotes from the text on this: "pet peeves, rants, annoyances and musings", "much ... very tangentially relevant", "some ... outright irrelavant." I agree with some and disagree with some. I think this chapter would have been better as a series of blog posts than a chapter in a book.

If you are using/planning to use TestNG and can ignore the rants, this is a good book.

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.