xUnit Test Patterns: Refactoring Test Code and over one million other books are available for Amazon Kindle. Learn more

Vous voulez voir cette page en français ? Cliquez ici.

Sign in to turn on 1-Click ordering.
Amazon Prime Free Trial required. Sign up when you check out. Learn More
More Buying Choices
Have one to sell? Sell yours here
Start reading xUnit Test Patterns: Refactoring Test Code on your Kindle in under a minute.

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

xUnit Test Patterns: Refactoring Test Code [Hardcover]

Gerard Meszaros
5.0 out of 5 stars  See all reviews (2 customer reviews)
List Price: CDN$ 78.99
Price: CDN$ 49.76 & FREE Shipping. Details
You Save: CDN$ 29.23 (37%)
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Only 5 left in stock (more on the way).
Ships from and sold by Amazon.ca. Gift-wrap available.
Want it delivered Tuesday, September 2? Choose One-Day Shipping at checkout.


Amazon Price New from Used from
Kindle Edition CDN $37.02  
Hardcover CDN $49.76  
Save Up to 90% on Textbooks
Hit the books in Amazon.ca's Textbook Store and save up to 90% on used textbooks and 35% on new textbooks. Learn more.
Join Amazon Student in Canada

Book Description

May 21 2007 0131495054 978-0131495050 1

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 




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


Frequently Bought Together

xUnit Test Patterns: Refactoring Test Code + Test Driven Development: By Example + Working Effectively with Legacy Code
Price For All Three: CDN$ 125.34

Customers Who Bought This Item Also Bought

Product Details

Product Description

About the Author

Gerard Meszaros is Chief Scientist and Senior Consultant at ClearStream Consulting, a Calgary-based consultancy specializing in agile development. He has more than a decade of experience with automated unit testing frameworks and is a leading expert in test automation patterns, refactoring of software and tests, and design for testability.

Excerpt. © Reprinted by permission. All rights reserved.

The Value of Self-Testing Code

In Chapter 4 of Refactoring Ref, Martin Fowler writes:

If you look at how most programmers spend their time, you'll find that writing code is actually a small fraction. Some time is spent figuring out what ought to be going on, some time is spent designing, but most time is spent debugging. I'm sure every reader can remember long hours of debugging, often long into the night. Every programmer can tell a story of a bug that took a whole day (or more) to find. Fixing the bug is usually pretty quick, but finding it is a nightmare. And then when you do fix a bug, there's always a chance that anther one will appear and that you might not even notice it until much later. Then you spend ages finding that bug.

Some software is very difficult to test manually. In these cases, we are often forced into writing test programs.

I recall a project I was working on in 1996. My task was to build an event framework that would let client software register for an event and be notified when some other software raised that event (the Observer GOF pattern). I could not think of a way to test this framework without writing some sample client software. I had about 20 different scenarios I needed to test, so I coded up each scenario with the requisite number of observers, events, and event raisers. At first, I logged what was occurring in the console and scanned it manually. This scanning became very tedious very quickly.

Being quite lazy, I naturally looked for an easier way to perform this testing. For each test I populated a Dictionary indexed by the expected event and the expected receiver of it with the name of the receiver as the value. When a particular receiver was notified of the event, it looked in the Dictionary for the entry indexed by itself and the event it had just received. If this entry existed, the receiver removed the entry. If it didn't, the receiver added the entry with an error message saying it was an unexpected event notification.

After running all the tests, the test program merely looked in the Dictionary and printed out its contents if it was not empty. As a result, running all of my tests had a nearly zero cost. The tests either passed quietly or spewed a list of test failures. I had unwittingly discovered the concept of a Mock Object (page 544) and a Test Automation Framework (page 298) out of necessity!

My First XP Project

In late 1999, I attended the OOPSLA conference, where I picked up a copy of Kent Beck's new book, eXtreme Programming Explained XPE. I was used to doing iterative and incremental development and already believed in the value of automated unit testing, although I had not tried to apply it universally. I had a lot of respect for Kent, whom I had known since the first PLoP1 conference in 1994. For all these reasons, I decided that it was worth trying to apply eXtreme Programming on a ClearStream Consulting project. Shortly after OOPSLA, I was fortunate to come across a suitable project for trying out this development approach--namely, an add-on application that interacted with an existing database but had no user interface. The client was open to developing software in a different way.

We started doing eXtreme Programming "by the book" using pretty much all of the practices it recommended, including pair programming, collective ownership, and test-driven development. Of course, we encountered a few challenges in figuring out how to test some aspects of the behavior of the application, but we still managed to write tests for most of the code. Then, as the project progressed, I started to notice a disturbing trend: It was taking longer and longer to implement seemingly similar tasks.

I explained the problem to the developers and asked them to record on each task card how much time had been spent writing new tests, modifying existing tests, and writing the production code. Very quickly, a trend emerged. While the time spent writing new tests and writing the production code seemed to be staying more or less constant, the amount of time spent modifying existing tests was increasing and the developers' estimates were going up as a result. When a developer asked me to pair on a task and we spent 90% of the time modifying existing tests to accommodate a relatively minor change, I knew we had to change something, and soon!

When we analyzed the kinds of compile errors and test failures we were experiencing as we introduced the new functionality, we discovered that many of the tests were affected by changes to methods of the system under test (SUT). This came as no surprise, of course. What was surprising was that most of the impact was felt during the fixture setup part of the test and that the changes were not affecting the core logic of the tests.

This revelation was an important discovery because it showed us that we had the knowledge about how to create the objects of the SUT scattered across most of the tests. In other words, the tests knew too much about nonessential parts of the behavior of the SUT. I say "nonessential" because most of the affected tests did not care about how the objects in the fixture were created; they were interested in ensuring that those objects were in the correct state. Upon further examination, we found that many of the tests were creating identical or nearly identical objects in their test fixtures.

The obvious solution to this problem was to factor out this logic into a small set of Test Utility Methods (page 599). There were several variations:

  • When we had a bunch of tests that needed identical objects, we simply created a method that returned that kind of object ready to use. We now call these Creation Methods (page 415).
  • Some tests needed to specify different values for some attribute of the object. In these cases, we passed that attribute as a parameter to the Parameterized Creation Method (see Creation Method).
  • Some tests wanted to create a malformed object to ensure that the SUT would reject it. Writing a separate Parameterized Creation Method for each attribute cluttered the signature of our Test Helper (page 643), so we created a valid object and then replaced the value of the One Bad Attribute (see Derived Value on page 718).
We had discovered what would become2 our first test automation patterns.

Later, when tests started failing because the database did not like the fact that we were trying to insert another object with the same key that had a unique constraint, we added code to generate the unique key programmatically. We called this variant an Anonymous Creation Method (see Creation Method) to indicate the presence of this added behavior.

Identifying the problem that we now call a Fragile Test (page 239) was an important event on this project, and the subsequent definition of its solution patterns saved this project from possible failure. Without this discovery we would, at best, have abandoned the automated unit tests that we had already built. At worst, the tests would have reduced our productivity so much that we would have been unable to deliver on our commitments to the client. As it turned out, we were able to deliver what we had promised and with very good quality. Yes, the testers3 still found bugs in our code because we were definitely missing some tests. Introducing the changes needed to fix those bugs, once we had figured out what the missing tests needed to look like, was a relatively straightforward process, however.

We were hooked. Automated unit testing and test-driven development really did work, and we have been using them consistently ever since.

As we applied the practices and patterns on subsequent projects, we have run into new problems and challenges. In each case, we have "peeled the onion" to find the root cause and come up with ways to address it. As these techniques have matured, we have added them to our repertoire of techniques for automated unit testing.

We first described some of these patterns in a paper presented at XP2001. In discussions with other participants at that and subsequent conferences, we discovered that many of our peers were using the same or similar techniques. That elevated our methods from "practice" to "pattern" (a recurring solution to a recurring problem in a context). The first paper on test smells RTC was presented at the same conference, building on the concept of code smells first described in Ref.

My Motivation

I am a great believer in the value of automated unit testing. I practiced software development without it for the better part of two decades, and I know that my professional life is much better with it than without it. I believe that the xUnit framework and the automated tests it enables are among the truly great advances in software development. I find it very frustrating when I see companies trying to adopt automated unit testing but being unsuccessful because of a lack of key information and skills.

As a software development consultant with ClearStream Consulting, I see a lot of projects. Sometimes I am called in early on a project to help clients make sure they "do things right." More often than not, however, I am called in when things are already off the rails. As a result, I see a lot of "worst practices" that result in test smells. If I am lucky and I am called early enough, I can help the client recover from the mistakes. If not, the client will likely muddle through less than satisfied with how TDD and automated unit testing worked--and the word goes out that automated unit testing is a waste of time.

In hindsight, most of these mistakes and best practices are easily avoidable given the right knowledge at the right time. But how do you obtain that knowledge without making the mistakes for yourself? At the risk of sounding self-serving, hiring someone who has the knowledge is the most time-efficient way of learning any new practice or technology. According to Gerry Weinberg's "Law of Raspberry Jam" SoC,4 taking a course or reading a book is a much less effective (though less expensive) alternative. I hope that by writing down a lot of these mistakes and suggesting ways to avoid them, I can save you a lot of grief on your project, whether it is fully agile or just more agile than it has been in the past--the "Law of Raspberry Jam" not withstanding.

Who This Book Is For

I have written this book primarily for software developers (programmers, designers, and architects) who want to write better tests and for the managers and coaches who need to understand what the developers are doing and why the developers need to be cut enough slack so they can learn to do it even better! The focus here is on developer tests and customer tests that are automated using xUnit. In addition, some of the higher-level patterns apply to tests that are automated using technologies other than xUnit. Rick Mugridge and Ward Cunningham have written an excellent book on Fit FitB, and they advocate many of the same practices.

Developers will likely want to read the book from cover to cover, but they should focus on skimming the reference chapters rather than trying to read them word for word. The emphasis should be on getting an overall idea of which patterns exist and how they work. Developers can then return to a particular pattern when the need for it arises. The first few elements (up to and include the "When to Use It" section) of each pattern should provide this overview.

Managers and coaches might prefer to focus on reading Part I, The Narratives, and perhaps Part II, The Test Smells. They might also need to read Chapter 18, Test Strategy Patterns, as these are decisions they need to understand and provide support to the developers as they work their way through these patterns. At a minimum, managers should read Chapter 3, Goals of Test Automation.

1 The Pattern Languages of Programs conference.

2 Technically, they are not truly patterns until they have been discovered by three independent project teams.

3 The testing function is sometimes referred to as "Quality Assurance." This usage is, strictly speaking, incorrect.

4 The Law of Raspberry Jam: "The wider you spread it, the thinner it gets."

Inside This Book (Learn More)
First Sentence
There are a lot of principles, patterns, and smells in this book-and even more patterns that couldn't fit into the book. Read the first page
Browse Sample Pages
Front Cover | Copyright | Table of Contents | Excerpt | Index | Back Cover
Search inside this book:

What Other Items Do Customers Buy After Viewing This Item?

Customer Reviews

4 star
3 star
2 star
1 star
5.0 out of 5 stars
5.0 out of 5 stars
Most helpful customer reviews
5.0 out of 5 stars Inspired to Test Dec 23 2007
I've been familiar with agile concepts of automated unit testing (AUT) and test-driven development (TDD) for awhile now. In the past few years I've made several attempts at incorporating AUT and TDD into my own personal workflow, but each attempt soon resulted in my abandoning the whole idea. The testing effort quickly outweighed the benefits. I've believed in the ideal of TDD, but I didn't see quite how to pull it off.

Then I bought XUnit Test Patterns by Gerard Meszaros. Wow! Finally the issues I've struggled with are being addressed. Okay, I must admit I'm not very plugged in to the online software development community, and I'm sure these issues have been discussed before. But this book looks special. I sense it's giving voice to these issues in a big way that's introducing many developers to these ideas for the first time. After all, it had to take time for this kind of book to be written. Time for the patterns to be developed through hard and frustrating work.

Rarely have I bought a thick book on software development and eagerly read every single word from cover to cover. But I have with this book. And I know I'll soon do it again. I'm even tempted to also purchase the PDF version of the book, just so I can reference it wherever I happen to be.

It's not the final word on AUT, but it has me embracing the ideal of TDD once more. The company I work for develops a huge OO-based enterprise software system with no automated tests. As Meszaros explains, this kind of legacy system is the most difficult for incorporating AUT (and daunting for those new to AUT). But at least now I feel like we have a good chance.
Was this review helpful to you?
5.0 out of 5 stars Comprehensive Aug. 3 2007
This book is advertised as "three books in one" which I originally figured was just the usual publisher's marketing. But it really delivers in all three areas: introductory narratives, discussion of test code smells, and of course, the testing patterns themselves.

Even if you have done automated unit testing using any of the xUnit frameworks in the past, it will be useful to read the introductory narratives. Meszaros accomplishes the difficult task of clearly describing all of the aspects of xUnit including fixture management. I say "difficult", because it can be hard to document something that is so familiar that you do every day. Even though most of this content is not new, it provides clear terminology, which is valuable in making the rest of the book understandable.

Mezaros writes in a clear and highly detailed style and the book appears suprisingly free of typos and grammatical errors, which is a nice change for technical books.

Don't be scared by the size of the book. There isn't anything unnecessary here, and even the glossary is comprehensive and useful.

Highly recommended!
Was this review helpful to you?
Most Helpful Customer Reviews on Amazon.com (beta)
Amazon.com: 4.6 out of 5 stars  23 reviews
45 of 45 people found the following review helpful
4.0 out of 5 stars All the important unit testing patterns and principles, but over-long Aug. 4 2007
By Thing with a hook - Published on Amazon.com
Let me start by stating the obvious: this is a patterns book about the organisation of tests and the workings of the xUnit family of unit testing frameworks. It is _not_ a book about Test Driven Development, although there is material that is pertinent to that. Given that the use of JUnit and TDD is pretty intertwined in the minds of many Java developers, it's worth making this distinction, so you know what sort of book you're getting. Speaking of JUnit, most of the code examples uses Java, although there are some examples in C#, VB and Ruby.

Like Martin Fowler's Patterns of Enterprise Application Architecture, the book is split into two main sections, a narrative that weaves together a lot of the patterns and strategies, and then a catalogue of individual patterns. Between the two, there is a catalogue of 'test smells', similar to the 'code smells' discussed by Fowler in Refactoring, which I would suggest can be read profitably with the narrative section, rather than used as reference material.

There are a lot of patterns here on the mechanics of xUnit, such as 'Test Runner', 'Garbage-Collected Teardown' and 'Named Test Suite'. I was a bit confused about who this material is aimed at -- maybe someone looking at porting xUnit to a new programming language would find it useful, but a lot of it is fairly obvious to anyone who's used an xUnit in a non-trivial fashion (and certainly, if you haven't done so, this book is not a format that makes for a good introduction), or requires playing against xUnit's strengths (e.g. not putting setup and teardown code in their eponymous methods), although there is good reason for doing so in some of the examples provided, such as databases.

Beyond this, there is some good stuff on design-for-testability patterns (e.g. dependency injection versus dependency lookup), value patterns to replace magic constants, custom assertions and custom creation and other utility methods to make the intent of tests more clear. This material, along with the test smells chapter, is where the real value of the book lies. It encourages the application of the same software engineering principles you would apply to your applications (encapsulation, intent-revealing names, Don't Repeat Yourself) as you would to your testing code, something that's surprisingly easy to overlook, at least in my experience.

Also, the material on 'Test Doubles' (mocks, stubs, dummies and their ilk) is extremely useful. It touches on designing with mocks only superficially, but it does provide a helpful taxonomy of what different classes of doubles do. Now, if only everyone would standardise on this nomenclature, it would make life a lot easier. I suggest we brandish this enormous book threateningly at anyone who refuses to toe the line, and that should do the trick.

Because, boy, this book is big (about 900 pages). To be honest, it's too big. I rarely complain about getting too much book for my money, but the likes of GoF, PoEAA and PoSA 1 manage to come in between 400-500ish pages, so there's no reason XTP couldn't. The advantage is that the patterns in the catalogue, which take up most of the space, stand alone, without requiring too much flicking backwards and forwards between patterns.

The disadvantage is that there is a lot of repetition, so unlike the three design patterns books I mentioned above, which I suspect most people read cover to cover (or maybe that was just me and I'm a complete freak), I would suggest only dipping into the catalogue as necessary. For instance, how much difference is there between the 'Testcase Class per Class', 'Testcase Class per Feature' and the 'Testcase Class per Fixture' patterns? Not a lot, as you might expect.

I definitely liked this book. I would have liked it even more if it came in at about half its size and I would have preferred more emphasis on test and assertion organisation than the mechanics of the xUnit framework, but maybe that would have been a different type of book to the one Gerard Meszaros intended. This is nonetheless a must buy for anyone who cares about unit testing.
15 of 15 people found the following review helpful
5.0 out of 5 stars Seminal Work in Test-Driven Development June 16 2007
By S. Gentile - Published on Amazon.com
We went over 2,000 unit tests this past week during Iteration 72 on our Agile project. Of course, over the course of the last 18-24 months we have removed some tests, and in many cases, refactored the existing tests many times. We also have been learning a whole lot about TDD and the actual domain that we are building and testing. As we were doing this, we were implicitly discovering Test Smells, and discovering test automation patterns. The value in establishing patterns, and more precisely a pattern language in a particular domain are substantial. It's not so much that the "collector" of patterns is defining something new (some often mistakenly criticize pattern books in that regard) that you didn't know, but defining a shared terminology of our practices that we keep doing over and over. To that end, the patterns themselves not only define a shared vocabulary but serve other functions, not the least of which is learning from others. An obvious example of this is Martin's PEAA collection of patterns that enables us to say things like PageController or Lazy Load or TableDataGateway and we all know what it means. In fact, when I am talking about Interaction versus State/Behavior type of testing on CB, and others here use much of this terminology, I am in fact, talking about patterns like TestDoubles and MockObjects, among others.

When I became aware that Gerard Meszaros ' xUnit Test Patterns book was going to ship Friday, I ordered it for overnight delivery on Saturday. I read well over 200 pages yesterday pretty much at one sitting, contented with a book that will change the face of the software industry, just as JUnit and all the other xUnit family have fundamentally altered software development for the better. Its definitely a big book at 944 pages, but it's not a book of excess, unnecessary pages. Rather it shows how hard it is to write defect-free software and the depth of the work that people are putting into this endeavor. The book uses Java as the language which obviously is no hardship to the C# programmer. Like most of the sound practices that have been evolving in the last ten years, this work has been evolving out of the terrific Java community.

Just like their are Code Smells, there are Test Smells, and writing good test code is just as hard and as worthy as writing good production code. Meszaros categorizes Test Smells into ProjectSmells, BehaviorSmells, and CodeSmells. Particularly interesting is his discussion in this regard to the commercial "record and playback" test automation products that have given test automation a bad name in many circles with their tendency to create FragileTests particularly with regard to Interface Sensitivity. Like many others, we were drawn in, and spent and wasted thousands of dollars with a vendor and exhibiting extreme Interface Sensitivity with the user interface. Their interface was not only unable to "pick up" most of the controls we use but even minor changes to the interface can cause tests to fail, even in circumstances in which a human user would say the test should pass. This only goes to support the notion many of us have talked about here about factoring a UI into MVP or MVC and not having logic in the "presentation."

Meszaros goes onto to provide very valuable discussions of Goals of Test Automation, Philosophies of Test Automation, and a Roadmap to Test Automation. We talk about things like Tests as Specification, also known as Executable Specification: "If we are doing test-driven development or test-first development, the tests give us a way to capture what the SUT should be doing before we start implementing it. They give us a way to specify the behavior in various scenarios captured in a form that we can then execute (essentially an "executable specification".) To ensure we are "building the right software", we must ensure that our tests reflect how the SUT will actually be used." We also talk about Tests as Documentation.

The main part of the book, of course, is the catalog of the patterns. Meszaros has provided a tremendous service to our community by not only cataloging and naming much of what we do, but also providing excellent discussions of why and how we do those things. I think, over time, this will be regarded as a seminal work in Software Development.
17 of 19 people found the following review helpful
5.0 out of 5 stars Fills an important void June 6 2007
By Gregor Hohpe - Published on Amazon.com
Writing good tests is not easy. Different developers have come up with many techniques to improve tests. You might have used Backdoor Manipulation to make tests faster or used Custom Assertions to make an Obscure Test more readable. Sometimes a failing test caused you to play Assertion Roulette while you were trying to figure out who the Mystery Guest in this test is and what role he plays.

Gerard documented these (and many more) smells and patterns to help you write better tests. If you have written tests, you have probably used some of them, but even then looking at the patterns described in this book will help you tune your technique. For example Custom Assertions should always take the actual and expected values as parameters, so assertMagicObjectsAreEqual(actual, expected) is good, assertEverythingIsAlright(actual) is bad. And now you have a name for this technique, which makes it easier to explain to your fellow developers what you are doing. At 800+ pages you are bound to find plenty of new techniques as well.

If you are worried that this is another work by the pattern weenies, rest assured. The book follows the very simple and pragmatic "How It Works" and "When to Use It" format also used by Martin Fowlers' Patterns of Enterprise Application Architecture.
6 of 6 people found the following review helpful
5.0 out of 5 stars A must-have for xUnit practitioners... July 4 2007
By Thomas Duff - Published on Amazon.com
By now, the concept of "patterns" in program design is pretty well accepted. And the concept of test-driven development has a solid foundation also. But are there certain "patterns" to building and running those tests? The answer is yes, and the book that covers it is xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. If you use any of the xUnit software in your development efforts, you need to have this book...

Part 1 - The Narratives: A Brief Tour; Test Smells; Goals of Test Automation; Philosophy of Test Automation; Principles of Test Automation; Test Automation Strategy; xUnit Basics; Transient Fixture Management; Persistent Fixture Management; Result Verification; Using Test Doubles; Organizing Our Tests; Testing with Databases; A Roadmap to Effective Test Automation
Part 2 - The Test Smells: Code Smells; Behavior Smells; Project Smells
Part 3 - The Patterns: Test Strategy Patterns; xUnit Basics Patterns; Fixture Setup Patterns; Result Verification Patterns; Fixture Teardown Patterns; Test Double Patterns; Test Organization Patterns; Database Patterns; Design-for-Testability Patterns; Value Patterns
Part 4 - Appendixes: Test Refactorings; xUnit Terminology; xUnit Family Members; Tools; Goals and Principles; Smells, Aliases, and Causes; Patterns, Aliases, and Variations
Glossary; References; Index

Most of the books that cover xUnit software do so from the perspective of a technical manual. Everything is geared to writing the actual code for the test. Meszaros takes a different tack. He covers more of the "why" behind test writing in xUnit, as well as the basic patterns and principles you should be aware of when you're putting together your tests. People new to xUnit will throw together tests without much thought as to the structure and robustness of that script. Meszaros maintains that much of the same care that goes into writing and designing programs should also go into the test scripts. Patterns such as In-line Setup, Chained Tests, State Verification, and many others can adjust your whole mindset towards what makes a solid and maintainable test script that will serve you well both now and down the road when you have to make changes to the program (and add more scripts to your test suite). The book is set up such that you can scan for basic ideas, and then go back to specific patterns for more information as the situations and needs arise. With the use of both actual code and UML diagrams, it's very easy to catch the gist of each pattern, as well as seeing how it would actually be implemented. Very good stuff here...

If you practice test-driven development (and you should), you have no doubt worked with your particular xUnit variant. This book is the next step in your learning, and it will make you a much better developer and tester...
5 of 5 people found the following review helpful
5.0 out of 5 stars A Must Have Reference June 15 2007
By James R. Carr - Published on Amazon.com
Anyone who is serious about automated testing on their project should go out and read this book ASAP. Like Patterns of Enterprise Application Architecture [Fowler] and Design Patterns [GoF] before it, Gerard Meszaros has put together a very through (if not large... the book is twice the size of PoEAA)reference and catalog of test patterns to make testing more efficient.

The book is rather voluminous, divided up into 3 parts. The first part, "The Narratives", is a refreshing lecture on the philosophy of test automation, a brief on test smells, test organization, and tests with external resources. Essentially an overview of several concepts involved in test automation.

Part 2, aptly titled "The Test Smells," covers some of the common test smells, such as "Hard-to-Test Code", "Fragile Test", and "Slow Test" just to name a few. These are organized in the format Symptoms, Impact, Troubleshooting Advice, and Causes, with the Causes section broken down by cause, with Symptoms, Root Cause, and Possible Solution listed for each. I was impressed with this section as I already recognized some of the smells, as well as having already applied some of the solutions listed in the past.

Part 3 is "The Patterns", which follows the form of most patten catalogs out there. This is the largest section as it makes up more than half of the book, covering a lot of a ground. The patterns are given in a similar form to the ones in PoEAA, and provide easy to follow examples and in depth analysis. I was happy to find myself applying two of the patterns in the section already on a current project.

Overall, great book. Highly Recommended. ;)
Search Customer Reviews
Only search this product's reviews

Look for similar items by category