Next Generation Java Testing: TestNG and Advanced Concepts and over one million other books are available for Amazon Kindle. Learn more
CDN$ 39.68
  • List Price: CDN$ 62.99
  • You Save: CDN$ 23.31 (37%)
Usually ships within 4 to 6 weeks.
Ships from and sold by
Gift-wrap available.
Have one to sell?
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See this image

Next Generation Java Testing: TestNG and Advanced Concepts Paperback – Oct 15 2007

See all 3 formats and editions Hide other formats and editions
Amazon Price New from Used from
Kindle Edition
"Please retry"
"Please retry"
CDN$ 39.68
CDN$ 39.68 CDN$ 44.79

2014 Books Gift Guide
Yes Please is featured in our 2014 Books Gift Guide. More gift ideas

Customers Who Bought This Item Also Bought

Product Details

  • Paperback: 512 pages
  • Publisher: Addison-Wesley Professional; 1 edition (Oct. 15 2007)
  • Language: English
  • ISBN-10: 0321503104
  • ISBN-13: 978-0321503107
  • Product Dimensions: 17.7 x 3 x 23.4 cm
  • Shipping Weight: 816 g
  • Average Customer Review: 5.0 out of 5 stars  See all reviews (1 customer review)
  • Amazon Bestsellers Rank: #183,945 in Books (See Top 100 in Books)
  • See Complete Table of Contents

Product Description

About the Author

Cédric Beust, a senior software engineer at Google, is an active member of the Java Community Process who has been extensively involved in the development of the latest Java release. He is the creator and main contributor to the TestNG project.

Hani Suleiman is CTO of Formicary, a consulting and portal company specializing in financial applications. He is one of two individual members who has been elected to the Executive Committee of the Java Community Process.

Excerpt. © Reprinted by permission. All rights reserved.

We're all in the business of software development. Code is written and then deployed. Once we've deployed the code, our customers will express pleasure or, depressingly often, displeasure.

For the last few decades, much has been written about how to minimize this displeasure. We have countless languages, methodologies, tools, management techniques, and plain old-fashioned mythology to help address this issue.

Some of these approaches are more effective than others. There has certainly been a renewed emphasis and focus on testing lately, along with the pleasures said testing would bring to developers and users alike.

Much has been written extolling the virtues of testing. It can make your code better, faster, and lighter. It can add some sorely needed spice to the drudgery of coding. It's exciting and new (and therefore worth trying), not to mention the feeling of responsibility and accountability it imparts; there's something mysteriously satisfying about adding a feature and having a test to prove you did it right.

Unfortunately, religion has also crept into the science of testing. You won't have to look far to find holy commandments or Persons of Authority handing down instructions either applauding or scolding certain testing behavior.

This book attempts to distill some of the wisdom that has emerged over the last few years in the realm of Java testing. Neither of us has ever had a job where we're paid to sell testing, nor has testing been forced on us. Neither of us works at a place where one methodology has been proclaimed the "winner" and must be followed religiously.

Instead, we're pragmatic testers. Testing to us is simply another valuable tool that helps us as part of the software development cycle. We're not particularly "test infected," the term coined by JUnit early on that's gained so much adoption. We write tests when and where it makes sense; testing is a choice and not an infectious disease for us.

As a result of this approach, we've noticed a rather large hole in our testing arsenal: Very few tools seem to be practical and to lend themselves to the sort of tests we'd like to write. The dominant force in Java testing is JUnit, and in many cases, it's easy and intuitive to think of a test we'd like to run. The main obstacle, however, ends up being the tooling and its inability to capture concepts that are second nature to us in the code we'd like to test--concepts such as encapsulation, state sharing, scopes, and ordering.

JUnit, for all its flaws, really brought the concept of testing to the forefront. No longer was it an ad hoc approach. Instead, tests now had a framework and a measure of standardization applied. JUnit-based tests could be easily automated and replayed in a variety of environments using any number of visualization tools. This ease of use encouraged its massive adoption and the increased awareness of Java testing in general.

Its success has also spilled over to a number of other languages, with ports to other languages all based on the same underlying concepts. As with any successful tool, however, the success came at a price. A subtle shift took place where instead of testing being the concern, and JUnit a tool to help achieve that, JUnit became the main focus, with testing that didn't fit in its narrow confines resulting in doubts about the test, rather than the tool.

Many will proclaim that a test that cannot be easily expressed in a simple "unit" is a flawed test. It's not a unit test since it has requirements beyond the simplistic ones that JUnit provides for. It's a functional test that happens later, after having built the unit building blocks. We find this argument perplexing, to say the least. Ultimately there is no one right way to do testing. It would be equally ridiculous to proclaim that development must start from implementing small units to completion first, before thinking of higher-level concerns. There are cases where that makes the most sense, just as there are many where it doesn't. Testing is a means to an end, and the end is better software. It's crucial to keep this in mind at all times.

Why Another Book about Testing?

This is a book about Java testing. Every chapter and section you will read in the following pages will discuss testing in some way or another. Regardless of what testing framework you use or whether you use tools that we don't cover, our goal is to show you some practices that have worked for us in some way. We also tried to draw general conclusions from our own experiences and use these to make recommendations for future scenarios that might arise.

Even though we use TestNG in this book to illustrate our ideas, we firmly believe that you will find some of it useful, whether or not you use JUnit--even if you're not programming on the Java platform. There are plenty of TestNG/JUnit-like frameworks for other languages (C# and C++ come to mind), and the ideas used in a testing framework are usually universal enough to transcend the implementation details that you will encounter here and there.

This book is about pragmatic testing. You will not find absolute statements, unfounded religious proclamations, and golden rules that guarantee robust code in this book. Instead, we always try to present pros and cons for every situation because ultimately you, the developer, are the one with the experience and the knowledge of the system you are working with. We can't help you with the specifics, but we can definitely show you various options for solving common problems and let you decide which one fits you best.

With that in mind, let's address the question asked above: Why anotherbook about testing?

There are plenty of books (some very good) about Java testing, but when we tried to look more closely, we came to the conclusion that hardly any books covered a broad topic that we found very important to our day-today job: modern Java testing.

Yes, using the adjective modern in a book is dangerous because, by nature, books don't remain modern very long. We don't think this book will be the exception to this rule, but it is clear to us that current books on Java testing do not properly address the challenges that we, Java developers, face these days. As you can see in the table of contents, we cover a very broad range of frameworks, most of which have come into existence only in the last three years.

In our research on prior art, we also realized that most books on Java testing use JUnit, which, despite its qualities, is a testing framework that has barely evolved since its inception in 2001. 1 It's not just JUnit's age that we found limiting in certain ways but also its very design goal: JUnit is a unit testing framework. If you are trying to do more than unit testing with JUnit (e.g., testing the deployment of a real servlet in an application server), you are probably using the wrong tool for the job.

Finally, we also cover a few frameworks that are quite recent and are just beginning to be adopted (e.g., Guice) but that we believe have such a such as TestNG that we just couldn't resist writing about them. Hopefully, our coverage of these bleeding-edge frameworks will convince you to give them a try as well.

Throughout the book, we have tried hard to demonstrate a pragmatic application of testing. Many patterns are captured in these pages. It's not an explicit list that we expect to be recited; rather, it's more of a group of examples to ensure you develop the right approach and way of thinking when it comes to testing code.

We achieve this through two separate approaches, the first of which is TestNG usage specifics. We discuss most of its features, explaining how and why they arose, as well as practical real-world examples of where they might be applicable. Through this discussion, we'll see how testing patterns can be captured by the framework and what goes into a robust maintainable test suite (and more importantly, what doesn't!).

The second aspect is showing how TestNG integrates with your existing code and the larger ecosystem of Java frameworks and libraries. Few of us are lucky enough to work on projects that are started completely from scratch. There are always components to reuse or integrate, legacy subsystems to invoke, or backward compatibility concerns to address. It would be equally foolish to demand redesigns and rewrites just to enable testing. Instead, we try to show how it's possible to work with existing code and how small incremental changes can make code more testable and more robust over time. Again, through this approach, a number of patterns emerge, along with more practices on how to write tests and approach testing in general.

We hope you enjoy reading this book as much as we enjoyed writing it. We feel very strongly about testing, but we feel equally strongly that it isn't a golden hammer in a world of nails. Despite what many would like to believe, there are no solutions or approaches that absolve you from the need to think and the need to understand your goals and ensure that your testing journey is a rational and well-considered one, where both the downsides and upsides have received equal consideration.


So, what is this book and who is it for? In short, it's for any Java developer who is interested in testing. We are also targeting developers who have been testing their code for quite a while (with JUnit or any other framework) but still find themselves sometimes intimidated by the apparent complexity of their code and, by extension, by the amount of effort needed to test it. With the help of the TestNG community over these years, we have made a lot of progress in understanding some of the best practices in testing all kinds of Java code, and we hope that this book will capture enough of them that nobody will ever be stuck when confronted with a testing problem.

This book uses TestNG for its code samples, but don't let that intimidate you if you're not a TestNG user: A lot of these principles are very easy to adapt (or port) to the latest version of JUnit.

Whether you use TestNG or not, we hope that once you close this book, you will have learned new techniques for testing your Java code that you will be able to apply right away.

1. JUnit 4, which came out in 2006, was the first update in five years that JUnit received, but at the time of writing, its adoption is still quite marginal, as most Java projects are still using JUnit 3.

Customer Reviews

5.0 out of 5 stars
5 star
4 star
3 star
2 star
1 star
See the customer review
Share your thoughts with other customers

Most helpful customer reviews

Format: Paperback Verified Purchase
Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again.

Most Helpful Customer Reviews on (beta) 11 reviews
33 of 38 people found the following review helpful
testng & rants Dec 9 2007
By Jeanne Boyarsky - Published on
Format: Paperback
"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.
19 of 22 people found the following review helpful
5 with a Few Qualms Nov. 27 2007
By R. Williams - Published on
Format: Paperback Verified Purchase
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.
10 of 11 people found the following review helpful
Practical Testing with a very good framework Feb. 1 2008
By D. M. Shetty - Published on
Format: Paperback
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.
5 of 5 people found the following review helpful
a few rants, but a ton of useful information Jan. 12 2009
By J. Brutto - Published on
Format: Paperback Verified Purchase
This book does more than go into TestNG, it also goes into some wonderful discussions about theory, general practices, etc. and how they explicitly apply to the Java world. The book offers an absolutely wonderful overview of TestNG's core feature set that has made it such a powerful replacement for JUnit. The book even goes further as it looks into extensions for TestNG (including other, integrating products), frameworks that can work in cooperation with it, etc. It even dismisses many of the myths that surround the world of testing and quality assurance.

Covering all of the essentials, this book will get you started right away in testing your source in a useful, organized manner. It will also help you find many of the traps that we have *ALL* allowed ourselves to fall into. There's just about no question left unanswered by this text in regards to working with TestNG and its associated technologies, concepts, etc.

The only two things I disliked about the book should be obvious to even the novice skill sets out there, but are easily breezed through if they annoy you that much. The first is that the rants about JUnit and other things were slightly too long. The second is that it does not acknowledge when it sticks its foot in its mouth.

Testing is loaded with "Do as I say, not as I do" mentalities/concepts. It's also faced with many "Sometimes you just *HAVE* to break the rules" scenarios. The book DOES break its own rules and, while it is obvious to the reader, does not take the time to truly justify why their own rule was being broken.

Great book... easy to read, follow and take to the real world.
Recommended read for all, but I recommend skipping the rants.
7 of 9 people found the following review helpful
Pragmatic Java Testing: TestNG and Author's Rants Sept. 30 2008
By Eric Jain - Published on
Format: Paperback
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!