Next Generation Java Testing TestNG and Advanced Concepts

by Beust, Cédric; Suleiman, Hani

• ISBN13: 9780321503107
• ISBN10: 0321503104
• Edition: 1st
• Format: Paperback
• Copyright: 2007-10-15
• Publisher: Addison-Wesley Professional

Summary

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

Foreword	p. xiii
Preface	p. xv
Acknowledgments	p. xxi
About the Authors	p. xxiii
Getting Started	p. 1
Beyond JUnit 3	p. 3
JUnit 4	p. 7
Designing for Testability	p. 8
TestNG	p. 17
Conclusion	p. 21
Testing Design Patterns	p. 23
Testing for Failures	p. 23
Factories	p. 34
Data-Driven Testing	p. 39
Asynchronous Testing	p. 67
Testing Multithreaded Code	p. 71
Performance Testing	p. 83
Mocks and Stubs	p. 90
Dependent Testing	p. 103
Inheritance and Annotation Scopes	p. 113
Test Groups	p. 119
Code Coverage	p. 132
Conclusion	p. 150
Enterprise Testing	p. 153
A Typical Enterprise Scenario	p. 154
A Concrete Example	p. 157
Test Implementation	p. 160
Exploring the Competing Consumers Pattern	p. 182
The Role of Refactoring	p. 186
Conclusion	p. 194
Java EE Testing	p. 197
In-Container versus Out-of-Container Testing	p. 198
In-Container Testing	p. 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
Servlets	p. 255
XML	p. 262
Conclusion	p. 266
Integration	p. 269
Guice	p. 280
DbUnit	p. 295
HtmlUnit	p. 303
Selenium	p. 310
Swing UI Testing	p. 312
Tests for Painting Code	p. 316
Continuous Integration	p. 320
Conclusion	p. 322
Extending TestNG	p. 325
The TestNG API	p. 325
BeanShell	p. 335
Method Selectors	p. 341
Annotation Transformers	p. 346
Reports	p. 355
Writing Custom Annotations	p. 366
Conclusion	p. 375
Digressions	p. 377
Motivation	p. 377
The TestNG Philosophy	p. 378
The Care and Feeding of Exceptionsv	p. 378
Stateful Tests	p. 382
The Pitfalls of Test-Driven Development	p. 385
Testing Private Methods	p. 388
Testing versus Encapsulation	p. 391
The Power of Debuggers	p. 392
Logging Best Practices	p. 394v
The Value of Time	p. 397
Conclusion	p. 399
IDE Integration	p. 401
Eclipse	p. 401
IntelliJ IDEA	p. 411
TestNG Javadocs	p. 421
JDK 1.4 and JDK 5	p. 421
Shortcut Syntax for JDK	p. 5
Annotations	p. 423
Annotation Javadocs	p. 423
The org
Testng
TestNG Class	p. 428
The XML API	p. 432
testng.xml	p. 435
Overview	p. 436
Scopes	p. 437
XML Tags	p. 437
Migrating from JUnit	p. 449
JUnitConverter	p. 449
Integrated Development Environments	p. 453
Incremental Migration and JUnit Mode	p. 455
Converting JUnit Code	p. 456
Index	p. 471
Table of Contents provided by Publisher. All Rights Reserved.

Excerpts

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