Next Generation Java Testing TestNG and Advanced Concepts

by ;
  • ISBN13:


  • ISBN10:


  • Edition: 1st
  • Format: Paperback
  • Copyright: 2007-10-15
  • Publisher: Addison-Wesley Professional
  • Purchase Benefits
  • Free Shipping On Orders Over $35!
    Your order must be $35 or more to qualify for free economy shipping. Bulk sales, PO's, Marketplace items, eBooks and apparel do not qualify for this offer.
  • Get Rewarded for Ordering Your Textbooks! Enroll Now
List Price: $59.99 Save up to $9.00
  • Buy New
    Add to Cart Free Shipping


Supplemental Materials

What is included with this book?

  • The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.
  • The eBook copy of this book is not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.


First definitive guide to next generation of testing technologies by creator of TestNG.

Author Biography

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.

Table of Contents

Forewordp. xiii
Prefacep. xv
Acknowledgmentsp. xxi
About the Authorsp. xxiii
Getting Startedp. 1
Beyond JUnit 3p. 3
JUnit 4p. 7
Designing for Testabilityp. 8
TestNGp. 17
Conclusionp. 21
Testing Design Patternsp. 23
Testing for Failuresp. 23
Factoriesp. 34
Data-Driven Testingp. 39
Asynchronous Testingp. 67
Testing Multithreaded Codep. 71
Performance Testingp. 83
Mocks and Stubsp. 90
Dependent Testingp. 103
Inheritance and Annotation Scopesp. 113
Test Groupsp. 119
Code Coveragep. 132
Conclusionp. 150
Enterprise Testingp. 153
A Typical Enterprise Scenariop. 154
A Concrete Examplep. 157
Test Implementationp. 160
Exploring the Competing Consumers Patternp. 182
The Role of Refactoringp. 186
Conclusionp. 194
Java EE Testingp. 197
In-Container versus Out-of-Container Testingp. 198
In-Container Testingp. 200
Java Naming and Directory Interface (JNDI)p. 207
Java Database Connectivity (JDBC)p. 210
Java Transaction API (JTA)p. 215
Java Messaging Service (JMS)p. 219
Java Persistence API (JPA)p. 225
Enterprise Java Beans 3.0 (EJB3)p. 236
Java API for XML Web Services (JAX-WS)p. 246
Servletsp. 255
XMLp. 262
Conclusionp. 266
Integrationp. 269
Guicep. 280
DbUnitp. 295
HtmlUnitp. 303
Seleniump. 310
Swing UI Testingp. 312
Tests for Painting Codep. 316
Continuous Integrationp. 320
Conclusionp. 322
Extending TestNGp. 325
The TestNG APIp. 325
BeanShellp. 335
Method Selectorsp. 341
Annotation Transformersp. 346
Reportsp. 355
Writing Custom Annotationsp. 366
Conclusionp. 375
Digressionsp. 377
Motivationp. 377
The TestNG Philosophyp. 378
The Care and Feeding of Exceptionsvp. 378
Stateful Testsp. 382
The Pitfalls of Test-Driven Developmentp. 385
Testing Private Methodsp. 388
Testing versus Encapsulationp. 391
The Power of Debuggersp. 392
Logging Best Practicesp. 394v
The Value of Timep. 397
Conclusionp. 399
IDE Integrationp. 401
Eclipsep. 401
IntelliJ IDEAp. 411
TestNG Javadocsp. 421
JDK 1.4 and JDK 5p. 421
Shortcut Syntax for JDKp. 5
Annotationsp. 423
Annotation Javadocsp. 423
The org
TestNG Classp. 428
The XML APIp. 432
testng.xmlp. 435
Overviewp. 436
Scopesp. 437
XML Tagsp. 437
Migrating from JUnitp. 449
JUnitConverterp. 449
Integrated Development Environmentsp. 453
Incremental Migration and JUnit Modep. 455
Converting JUnit Codep. 456
Indexp. 471
Table of Contents provided by Publisher. 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 wh

Rewards Program

Write a Review