ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck)) [ペーパーバック]

This review originally appeared on my blog...

ATDD is a relatively hot topic that has been getting more and more coverage both in the press and the blogosphere. I also have the benefit of knowing and have collaborated with the author of "ATDD By Example" over the past few years, so I could make this the shortest book review ever and just say "Markus Gärtner is my bud, he's awesome, his book is awesome, so go buy his book!" For those of you out there who suffer from "TL;DR", there ya' go, easy as that.

For the rest of you, you probably want to know what I really think. ATDD is a neat subject, it is a theoretical thing of beauty when it's explained at its simplest level, but what is it truly, and how does it work in a practical sense? Does it work in a practical sense? How can an everyday average tester involved in everyday testing work with this? And do I have to know Cucumber, RSpec and Ruby to have this book be worthwhile?

First and foremost, Markus explains the structure and the goals of ATDD very well. He brings his own experiences and makes examples based on things that exist in the real world, and while the examples are simple applications, generally speaking, they have enough meat to show how they actually work and demonstrate realistic issues that real developers and testers will actually face while trying to use ATDD.

Part I lets the tester follow along as Markus steps through a sample application. Many testers will chuckle when they see exactly what application he chooses; it's famous among the Weekend Testing crowd in particular; ParkCalc!!! He takes us through a very real and applicable workshop style approach, where testers, developers and the product owner determine the requirements, implement the requirements, and then create the tests, using Cucumber and Ruby for this first example. We see first steps, mistakes made, refactoring, and expansion of the application and requirements as we learn more and understand more of the domain, plus ways that we can recognize areas that we can reuse.

Part II takes us through a more elaborate example, testing the traffic light rules in Germany, this time using Java and FitNesse. By taking two different approaches and two different development environments, Markus makes the book relevant to multiple audiences, so that, instead of focusing on the tooling and the language, the reader focuses on the practices and methods used to make ATDD work.

Part III focuses on a number of topics that can help the everyday tester, developer or project manager get more out of ATDD. By stepping away from the tooling approaches of the previous two sections, Markus helps answer questions and deal with issues that are universal. Starting with developing examples to help drive the development process, as well as how to use them, format them and leverage them using pairwise testing, domain testing and boundaries, collaborating with the development team and providing testing acumen and input, making our automation as a literal analog of the requirements and specifications. In addition, taking the time to separate as much of the test details from the data that drives those tests (variables, keywords, etc.) can help make the tests we develop more robust, capable and long-lived.

Three appendices are provided, each covering basic details of three common ATDD testing frameworks; Cucumber, FitNesse, and Robot Framework. The reader will need to reference other documentation to maximize the use of these tools, but each Appendix will get the user in question up and running with the basics of all three approaches.

Beyond the examples, the main point that everyday testers will come away from this book knowing is that Acceptance Test Driven Development is Software Development, and they play a critical part in that process. If they do any type of test automation, they are developing software, and they should use the same practices, methods and methodologies that software developers use. Even if you are not specifically a coder, or you consider your skill set rudimentary, there is a lot to consider here that will help you get closer to understanding the development process and how you can contribute to it in your role as a tester.

ATDD by Example is a book that reward repeated reading. It's likely that you will get one message the first time through, and after practicing with the examples for awhile, you will give it a second pass and pick up many new things you didn't catch the first time. In short, ATDD by Example is a book that you will likely refer to on a regular basis until you get the concepts hard wired. Even then, there will be a lot of interesting tidbits that you will probably catch on as you read through it several times. Barring that, if you'd like to be more "quick on the uptake", then make sure to read Part III a few times, as it encapsulates much of the philosophy and methods that will be the most helpful to testers and developers looking to implement this approach.

Again, I could have saved you a lot of time by having you just read the first paragraph, but hey, now you know why I said it.

If you are interested in Acceptance Test-Driven Development, Behavior-Driven Development (BDD), Specification by Example, Agile Acceptance Testing, or Story Testing this is a great place to start.

The book is broken down into three parts. The first two are end to end case studies showing how to execute Acceptance Test-Driven Development. The first case study is with a team and the second one is the reader working with the author to develop a solution.

Part one builds an online parking cost calculator. It introduces specification workshops, wishful thinking, and collaboration as key ingredients to successful testing. Cucumber and Selenium are used to automate tests.

Part two builds a traffic light software system. In this part of the book the author makes use of FitNesse and SLiM to automate tests. This part is all about discovering your domain, driving your production code with your acceptance tests, and he brings to light how important your testing code is.

The third part of the book is the Principles of Acceptance Test-Driven Development. In this part of the book the author highlights the principles that are used in the examples in the first two parts of the book.

The third part includes advice on creating, refining, and managing examples, how to work collaboratively, how to automate, and how test cleanly.

The book ends with three appendixes that introduce some of the tools used throughout the book. They cover Cucumber, FitNesse ,and Robot Framework.

One of the things I liked most about this book is the examples the author uses. They are real world and they really allow him to bring to light the points he makes throughout the book.

Both of case studies are available for download. They are well organized and usable.

The author has a great writing style which makes the book a very enjoyable read. You can read this cover to cover very quickly.

I found the advice and the working examples very valuable. Like I said in the beginning of this review, I highly recommend this book to anyone looking for down to earth practical advice on Acceptance Test-Driven Development, Behavior-Driven Development (BDD), Specification by Example, Agile Acceptance Testing, or Story Testing.

A good ATDD primer for beginners. Those who have already experienced ATDD or have read Specification by Example: How Successful Teams Deliver the Right Software, The RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and Friends (The Facets of Ruby Series) and The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers) would uncover few secrets. Although I have to admit that Part 3 about principles and values is a good summary to refer to if you need to quickly refresh your memory or teach someone else the ATDD discipline.