- Series: Addison-Wesley Signature Series (Beck)
- Paperback: 240 pages
- Publisher: Addison-Wesley Professional; 1 edition (July 6, 2012)
- Language: English
- ISBN-10: 0321784154
- ISBN-13: 978-0321784155
- Product Dimensions: 6.3 x 0.5 x 9.1 inches
- Shipping Weight: 15.2 ounces (View shipping rates and policies)
- Average Customer Review: 12 customer reviews
- Amazon Best Sellers Rank: #1,273,661 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck)) 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Frequently bought together
Customers who bought this item also bought
About the Author
Markus Gärtner, works as an agile tester, trainer, coach, and consultant with it-agile GmbH, in Hamburg, Germany. He founded the German Agile Testing and Exploratory workshop in 2011, and cofounded the European chapter of Weekend Testing in 2010. A black-belt instructor in the Miagi-Do school of software testing, he contributes to the Agile Alliance FTT-Pattern writing community and the Software Craftsmanship movement. Gärtner regularly presents at agile and testing conferences around the world, has written extensively about agile testing, and regularly teaches ATDD and context-driven testing. He blogs at shino.de/blog.
Top customer reviews
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.
My first pass through the book was confusing especially with ambiguous terms like code, supporting code and glue code without a clear distinction. In combination with the increasing complexity of the examples, and refactoring kicking in, even after a second pass through the book I still don't fully get the TDD descriptions in this book.
Overall the book is still thoroughly written with a balanced set of practical examples.