Markus Gärtner - ATDD by Example: A Practical Guide to Acceptance Test-Driven Development

A Practical Guide to Acceptance Test-Driven Development

Markus Grtner

Upper Saddle River, NJ Boston Indianapolis San Francisco
New York Toronto Montreal London Munich Paris Madrid
Capetown Sydney Tokyo Singapore Mexico City

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact:

U.S. Corporate and Government Sales
(800) 382-3419

For sales outside the United States, please contact:

International Sales

Visit us on the Web: informit.com/aw

Library of Congress Cataloging-in-Publication Data

Grtner, Markus, 1979
ATDD by example / Markus Grtner.
p. cm.
Includes bibliographical references and index.
ISBN-10: 0-321-78415-4 (pbk. : alk. paper)
ISBN-13: 978-0-321-78415-5 (pbk. : alk. paper)
1. Agile software development Case studies. 2. Automation. 3. Systems engineering. I. Title.
QA76.76.D47G374 2013
005.1dc23 2012016163

Copyright 2013 Pearson Education, Inc.

All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. To obtain permission to use material from this work, please submit a written request to Pearson Education, Inc., Permissions Department, One Lake Street, Upper Saddle River, New Jersey 07458, or you may fax your request to (201) 236-3290.

ISBN-13: 978-0-321-78415-5
ISBN-10: 0-321-78415-4
Text printed in the United States on recycled paper at Courier in Westford, Massachusetts.
First printing, July 2012

To my wife Jennifer, my pet-son Leon, and our daughter Katrin,
who allowed me to spend way too little time
with them while writing this.

There is a curious symmetry to the way this book presents Acceptance Test-Driven Development and the way software is developed with ATDD. Just as there is an art to picking the specific examples of program behavior that will elicit the correct general behavior for the system, there is an art to picking specific examples of a programming technique like ATDD to give you, the reader, a chance to learn the technique for yourself. Markus has done an admirable job in selecting and presenting examples.

To read this book you will need to read code. If you follow along, you will have the opportunity to learn the shift in thinking that is required to succeed with ATDD. That shift is, in short, to quickly go from, Heres a feature Id like, to How are we going to test that? Heres an example. Reading the examples, you will see, over and over, what that transition looks like in various contexts.

What I like about this code-centric presentation is the trust it shows in your powers of learning. This isnt 12 Simple Rules for Testing Your Web App printed on intellectual tissue paper that falls apart at first contact with the moisture of reality. Here you will read about concrete decisions made in concrete contexts, decisions that you could (and that, if you want to get the most out of this book, you will) disagree with, debate, and decide for yourself.

The latter portions of the book do draw general conclusions, summarizing the principles at work in the examples. If you are someone who learns more efficiently when you are familiar with general concepts, that will be a good place to start. Regardless, what you get out of this book is directly proportional to the investment you are willing to make in following the examples.

One of the weaknesses of TDD as originally described is that it can devolve into a programmers technique used to meet a programmers needs. Some programmers take a broader view of TDD, facilely shifting between levels of abstraction for their tests. However, with ATDD there is no ambiguitythis is a technique for enhancing communication with people for whom programming languages are foreign. The quality of our relationships, and the communication that underlies those relationships, encourages effective software development. ATDD can be used to take a step in the direction of clearer communication, and ATDD by Example is a thorough, approachable introduction.

Kent Beck

Too many software projects fail to deliver what their customers request. Over the years, Ive heard scores of project customers explain the failures: The developers dont pay attention to what we ask them to build. And Ive heard hundreds of developers explain the failures: The customers dont tell us what they want. Most of the time they dont even know what they want.

Ive observed enough projects to come to a different conclusion: Describing a software systems responsibilities is hard. It requires speaking and listening with precision that is rareand rarely so necessaryin normal human interactions. Writing good software is hard. Testing software well is hard. But the hardest job in software is communicating clearly about what we want the system to do.

Acceptance Test-Driven Development (ATDD) helps with the challenge. Using ATDD, the whole team collaborates to gain clarity and shared understanding before development begins. At the heart of ATDD are two key practices: Before implementing each feature, team members collaborate to create concrete examples of the feature in action. Then the team translates these examples into automated acceptance tests. These examples and tests become a prominent part of the teams shared, precise description of done for each feature.

What is shared understanding worth? One developer at an ATDD workshop explained it this way: Once we started to work together to create examples, I started to care about the work we were doing. I finally understood what we were building and why. Even more importantly, I knew that the whole team understood what we were trying to accomplish. Suddenly we all had the same goalwe were all on the same team.

ATDD helps us not only to know when were done, but also to know when were making progress. As we automate each test and write the software that passes the test (and all of the previous tests), the examples serve as signposts along the road to completion. And because each example describes a responsibility that customers value, we can have confidence that not only are we making progress, were making progress that matters.

Okay, Ive listed a few of ATDDs key features and a few of its key benefits. Thats the easy part. As for the heavy lifting: How do you actually do this stuff so that it works in the real world? Ill leave that to Markus Grtner. In