Automated testing is a cornerstone of agile development. An effective testing strategy will deliver new functionality more aggressively, accelerate user feedback, and improve quality. However, for many developers, creating effective automated tests is a unique and unfamiliar challenge.

xUnit Test Patterns is the definitive guide to writing automated tests using xUnit, the most popular unit testing framework in use today. Agile coach and test automation expert Gerard Meszaros describes 68 proven patterns for making tests easier to write, understand, and maintain. He then shows you how to make them more robust and repeatable--and far more cost-effective.

Loaded with information, this book feels like three books in one. The first part is a detailed tutorial on test automation that covers everything from test strategy to in-depth test coding. The second part, a catalog of 18 frequently encountered "test smells," provides trouble-shooting guidelines to help you determine the root cause of problems and the most applicable patterns. The third part contains detailed descriptions of each pattern, including refactoring instructions illustrated by extensive code samples in multiple programming languages.

Topics covered include

• Writing better tests--and writing them faster

• The four phases of automated tests: fixture setup, exercising the system under test, result verification, and fixture teardown

• Improving test coverage by isolating software from its environment using Test Stubs and Mock Objects

• Designing software for greater testability

• Using test "smells" (including code smells, behavior smells, and project smells) to spot problems and know when and how to eliminate them

• Refactoring tests for greater simplicity, robustness, and execution speed

This book will benefit developers, managers, and testers working with any agile or conventional development process, whether doing test-driven development or writing the tests last. While the patterns and smells are especially applicable to all members of the xUnit family, they also apply to next-generation behavior-driven development frameworks such as RSpec and JBehave and to other kinds of test automation tools, including recorded test tools and data-driven test tools such as Fit and FitNesse.

Visual Summary of the Pattern Language 
Foreword
Preface
Acknowledgments
Introduction
Refactoring a Test
PART I: The Narratives
Chapter 1 A Brief Tour
Chapter 2 Test Smells
Chapter 3 Goals of Test Automation
Chapter 4 Philosophy of Test Automation
Chapter 5 Principles of Test Automation
Chapter 6 Test Automation Strategy
Chapter 7 xUnit Basics
Chapter 8 Transient Fixture Management
Chapter 9 Persistent Fixture Management
Chapter 10 Result Verification
Chapter 11 Using Test Doubles
Chapter 12 Organizing Our Tests
Chapter 13 Testing with Databases
Chapter 14 A Roadmap to Effective Test Automation
PART II: The Test Smells 
Chapter 15 Code Smells
Chapter 16 Behavior Smells
Chapter 17 Project Smells
PART III: The Patterns 
Chapter 18 Test Strategy Patterns
Chapter 19 xUnit Basics Patterns
Chapter 20 Fixture Setup Patterns
Chapter 21 Result Verification Patterns
Chapter 22 Fixture Teardown Patterns
Chapter 23 Test Double Patterns
Chapter 24 Test Organization Patterns
Chapter 25 Database Patterns
Chapter 26 Design-for-Testability Patterns
Chapter 27 Value Patterns
PART IV: Appendixes
Appendix A Test Refactorings  
Appendix B xUnit Terminology 
Appendix C xUnit Family Members
Appendix D Tools
Appendix E Goals and Principles
Appendix F Smells, Aliases, and Causes
Appendix G Patterns, Aliases, and Variations
Glossary
References 
Index 

Amazon.com® Reader Reviews (Ranked by Helpfulness)

Average Amazon.com® Rating:  Based on 14 Ratings

Awesome book must have for any software developer - 2009-11-18
Reviewer Rating:
Our team has been doing TDD for 6 years since the seminal Kent Beck book.
We as a team have learnt read and improved our practice over these years but this book has had the most impact on how 2 do TDD properly.
It has significantly improved our code and our testing practices.
Many of the leasons we learnt where emphasised and standardised in this book.
All I can say is that you will save yourself years and years of hard knocks learning if you read this book first.
By following the patterns in this book we have been more easily able to implement the principles in Kent's book.

Brett

Found it - 2009-10-30
Reviewer Rating:
It's what I was looking for. It is giving me a good reference and compass to TDD.

Good Desk Reference - 2009-09-09
Reviewer Rating:
Good book, I keep it on my desk at work. There is a pretty substantial website with nearly the same information online, however even after reading most of that site, I still chose to get the paper copy. Selenium, the popular open source functional automated testing tool is based on xUnit, so it's not just for programmers, but also QA.

More xUnit patterns than you would wish! - 2009-06-23
Reviewer Rating:

xUnit Test Patterns by Gerard Meszaros is a huge book. It is almost 900 pages of patterns to be used for test automation and for unit testing. This book contains a huge amount of useful knowledge for developers and is, without a doubt, the most thorough book on writing well-structured unit tests. The largest drawback of the book is its size and the amount of duplication.

The book consists of three parts. The first part is normal prose introducing the patterns and their contexts. The second part is a catalog of test smells and the last part (which is most of the book) describes the test patterns.

The first part of the book is excellent. It contains a couple of chapters related to test automation that are not specific to xUnit test automation. Chapter two introduces test smells, which I found very helpful. Chapter three contains the goals of test automation. This was one of the clearest descriptions I've seen which answer the question "why do we want to do this in the first place." The next chapters are about philosophy (e.g. TDD), principles and strategy. Chapter second introduces xUnit basics and the rest of the chapters of this part are narratives around the pattern sets (chapters) which are introduces further on in the book. The first part is about 180 pages of the book and is definitively worth reading completely. The individual chapters are short and easy to read.

The second part of the book covers test smells. The test smells are grouped intro three categories: code smells, behavior smells and project smells. These smells are also linked to each other, explaining what the "higher level smell" is caused by. I'm afraid I've seen all the smells in real life in the past and thus this part was very recognizable. Nowadays, I often send these smells to people I work with, since Gerard described them perhaps better than I ever could. The test smells are less than a hundred pages

The third part of the book are the test patterns. They are grouped in 'test pattern categories' with each category containing as little as four and as much as ten patterns. The pattern format Gerard uses is clear and easy to read. The largest drawback is that the pattern format causes quite a lot of duplication, especially across patterns. This is because the book is written so that each pattern can be read independently of others. This is good, but for people who read whole books (me) it causes the book to be somewhat boring to read (even though the content is interesting, just felt bored when reading again that there is one exception to object per test-case implementation of most xUnit frameworks).

The first chapter in part three is test strategy patterns, describing different approaches to testing (and this one is not specific to xUnit tests). The next chapter introduces xUnit frameworks written down in pattern form. Fixture setup is next in which the author describes the advantages and disadvantages for fresh vs shared fixtures and how to set them up. Chapter 21 then dives into the assertion parts of an xUnit framework describing the difference between state and behavior verification. Patterns such as custom assertions are frequently used in well-written test code. Next are the teardown patterns in which the authors somewhat promote the automated teardown (something I've not encountered very often in development). Chapter 23 is probably one of the best known chapters where Gerard categorizes test doubles (mocks/stubs/fakes) and describes when to use which term and why? This terminology is far from standardized and his effort to bring clarity in these terms is much appreciated. Next are test organization patterns such as how and where do you split your test case. Chapter 25 covers working with databases. Chapter 26 some general miscellaneous pattern in design which promote low coupling and thus increase testability. The final chapter relates to values within your tests.

The book also (for if this wasn't enough for you) contains over a hundred pages of appendixes. The refactorings, terminology mapping and glossary are useful.

Gerards book is huge. It contains useful insights related to unit testing and writing clean test code. From that perspective, this book is recommended for everyone serious about writing well-factored unit tests. However, the book also contains relative trivial things and, as mentioned, it contains a huge amount of duplication between different parts. This means that perhaps reading the book from cover to cover might not be the best approach :) Part one and two should definitively be read completely, but the patterns in chapter 3 are better browsed and read when needed or e.g. one per week. Another annoying part in the book, for me, was the way Gerard uses comments. Most comments in the code were not useful and made the code obscure and hard to read at times. Wished he had left them out (though, I guess this relates to coding style a lot).

Conclusion. Definitively worth reading or at least browsing for anyone serious about xUnit and test automation. Because of the duplication and the comments, I'd rate it four out of five stars. Personally I'd rather see a small 100 page book containing the summary and conclusions of what Gerard is talking about. It doesn't exist yet, so this book is, at this moment, the best on this particular subject.

Much needed addition for those using TDD - 2009-05-14
Reviewer Rating:
x/Unit patterns is a great book that fills a void I unconsciously would run into in projects using TDD. While several great books have been written about how to design and refactor our application code not much critical practical attention has been given to how to write test code. Most of it has been "do what I do" or heated discussions on why one strategy is better than another. I would often see "smells" end up in my test code, which I would attempt to refactor out. Yet, since I am still learning TDD I would often re-refactor my TDD code because I would often change my mind about why I made a change. I would also question whether or not I really was improving my project code by refactoring my TDD code.

xUnit Test Patterns definitely is a great addition to this space and fills a much needed gap. It helps put much needed background, concrete analysis and details around these areas. It will easily become a staple in the modern developer's reference collection.

This is not an intro to TDD book. If you do not use TDD and are wondering just what it is I would suggest you look elsewhere. If I had been given this book when I was entering the TDD space I would have been overwhelmed.

If you have used TDD on a project or two, with varying success, this would be a great book. It's a very easy read with a basic understanding of TDD. It opened my eyes on exactly why TAD (test after development) was much worse than simply "don't do it that way". It allows me to help explain TDD much better than saying, "just because you're supposed to". It also lays out a very detailed analysis on why you may or may not want to use fresh test fixtures versus shared as well as using persistent data. Both can be very hot controversial issues, yet Gerard explains the very fundamental reason behind the various strategies and where they may each be used with confidence. Of course, he explains why it may be very bad to use in certain situations, which are usually producing smells in our test code.

If you are an academic in this space (not just the casual user) and love the other Fowler books I would definitely recommend you add this to your collection. As I mentioned above, it establishes concrete naming conventions (based on original papers and commentaries) and provides a very detailed analysis of much of the current discussions in this space.

In the first half Gerard gives a very thorough tour through the TDD space including the benefits of using TDD, various strategies and their pros/cons, details of how most xUnit frameworks work and so on. Most of this is probably fairly familiar ground for those who are intermediate in TDD but it's a very quick read through. It filled in a few holes for me, but most importantly, like other refactoring/patterns books it helps put a concrete framework and names around the various methods. It helps facilitate great conversations where developers using TDD can speak on a common ground, an area that, at least in my circles, has been lacking.

The 2nd half details the actual patterns. Much in Fowler-academic pattern style, each pattern is listed with its name, what it attempts to accomplish, pros/cons and samples of use. He includes a vast amount of patterns, many of which I have ran into yet not been able to put my finger on why I decided to use it in one project and not another. He also makes a great case why the same pattern may be very useful in one context but an anti-pattern in another. Looking at the various pros/cons I really began to fill out my arsenal, if you will, with strategies I used to dismiss, however, in certain difficult contexts they would have actually fit the need perfectly.

If you have been using TDD in your projects, with whatever level of success, I would definitely recommend you add this book to your collection. As I said above, it's a quick yet detailed read and adds much needed tools to your TDD tool belt.

Browse Similar Topics

Top Level Categories:
Software Engineering

Sub-Categories:
Software Engineering > OOP