Preface

In this book I give an entry-level introduction to the practice that has become known as Acceptance Test-Driven Development—or ATDD. When I first came across the term ATDD in 2008, I assumed that it was artificial and unnecessary. It seemed superfluous to me as I had learned test-driven development in 2008 and found it sufficient. In the end, why would I need to test for acceptance criteria?

“Time wounds all heels” [Wei86]. So, four years later I find myself writing a book on what has become known as Acceptance Test-Driven Development. Throughout 2009 I ran into Gojko Adzic, who had just finished his book Bridging the Communication Gap [Adz09]. He gave me a copy of that book, and I immediately started to read it on my way back from London. Once I had finished it, I had a good understanding about what ATDD is and why we should avoid that name.

But why did I still use the name ATDD by Example for the paper stack you hold in your hands?¹

On the Name

ATDD has been around for some time now. It is known by different terms. Here is an incomplete list:

• Acceptance Test-Driven Development

• Behavior-Driven Development (BDD)

• Specification by Example

• Agile Acceptance Testing

• Story Testing

From my perspective, any of these names comes with a drawback. Acceptance Test-Driven Development creates the notion that we are finished with the iteration once the acceptance tests pass. This is not true, because with any selection of tests, the coverage is incomplete. There are gaps in the net of tests. In the testing world, this is well known as the impossibility to test everything. Instead we know exactly we are not finished when an acceptance test fails—as Michael Bolton put it.

Despite arguing for one name or another, I decided to put a selection of possible alternatives here and have the readers decide which fits best their need. In the end it does not matter to me what you call it, as long as it’s working for you. The world of software development is full of misleading terms and probably will stay so for some more years. Software engineering, test automation, test-driven development are all misleading in one way or another. As with any abstraction, don’t confuse the name for the thing. The expert knows the limitations of the name of the approach.

But why have there been different names for a similar approach? The practices you use may very well differ. Having visited and consulted multiple teams in multiple companies on ATDD, they all have one thing in common: Each team is different from the others. While one practice might work for your team in your current company, it might fail dramatically in another. Have you ever wondered about the answer “it depends” from a consultant? This is the source of it.

For his book Specification by Example [Adz11], Gojko Adzic interviewed more than fifty teams that apply ATDD in one form or another. What he found is a variety of practices accompanying the ATDD approach. All of the teams that apply ATDD successfully start with a basic approach, then revisit it after some time, and adapt some changes in order to fit their particular context. Starting with a lightweight process and adapting new things as you find problems is a very agile way of implementing any approach. As you apply ATDD, keep in mind that your first set of practices is unlikely to solve all your problems. Over time you will adapt the solution process as you gain more and more experience.

Why Another Book on ATDD?

While Gojko describes many patterns of successful ATDD implementations, I found there is a major gap in the books on ATDD up until now. There is a considerable difference between advanced adopters of a skill or approach and entry-level demands for the same skill or approach.

When going through the literature on ATDD, I found several books that explain ATDD on an advanced level by referring to principles. For an advanced learner, it is easy to apply principles in their particular context. However, this does not hold for a novice on the same topic. A novice needs more concrete directions in order to get started. Once a person gains experience with the basics, he or she can start to break free from the hard constraints of the approach.

Novices learn best by following a recipe, but by no means is this book a cookbook on ATDD. With the examples in this book, I provide two working approaches to ATDD and expose the thought processes of the people involved. The novice learner can use these to get started with ATDD on her team. As we go along, I provide pointers to more in-depth material.

The basic idea is taken from Kent Beck’s Test-Driven Development: By Example [Bec02]. Beck provides two working examples on Test-Driven Development and explains some of the principles behind it in the end. It is intended as an entry-level description of TDD and provides the novice with enough learning material to get started—assuming that through reflection and practice TDD can be learned. The same holds true to some degree for this book as well.

Vocabulary

Throughout the book I will use several terms from the Agile software development world. Realizing that not everyone knows about Agile software development, a brief introduction of some terms is in place.

Product Owner In the Agile method Scrum three roles are defined: the development team, the ScrumMaster, and the Product Owner. The Product Owner is responsible for the success of the product that the team will build. He or she sets priorities for the features that the team will be implementing and works together with other stakeholders to derive them. He or she is also the customer representative for the team and decides about details in that function—and has to negotiate with the other stakeholders about this.

Iteration, or Sprint Agile development relies on a regular cycle called the iteration or Sprint in Scrum. These are short bursts where the team implements a single product increment that is potentially shippable. Common iteration lengths vary between one and four weeks.

User Story A user story is a limited set of functionality that the team feels comfortable implementing over the course of a single iteration. These are tiny slices through the functionality. Usually a team strives to implement several user stories in one iteration. The business representative or product owner is responsible for defining these stories.

Taskboard Most Agile teams plan their work on a board visually accessible to anyone. They use cards to indicate what they are working on. The taskboard usually has several columns, at least ToDo, Doing, and Done. As the work proceeds, the team updates the taskboard to reflect this.

Story Card User stories are usually written on real cards. During the iteration, the cards are put onto the team’s taskboard.

Standup Meeting, Daily Scrum At least once per day team members update themselves on the current state of the iteration. The team gets together for 15 minutes and discusses how they can finish currently open tasks until the end of the iteration.

Product Backlog, Sprint Backlog The Product Owner in Scrum organizes unimplemented stories in a product backlog. He or she is responsible for updating the backlog whenever new requirements enter. When the team gets together to plan the next sprint, the team members identify a backlog for the next sprint length. This is called the Sprint Backlog. The selected stories from the Product Backlog automatically become part of the Sprint Backlog. The Sprint Backlog is most often organized on the taskboard after the planning meeting.

Refactoring Refactoring is changing the structure of the source code without changing what it does. Usually I refactor code before introducing changes. By refactoring my code I make the task of implementing the upcoming changes more easy.

Test-Driven Development (TDD) In test-driven development you write one single test that fails, write just enough code that makes this failing test pass (and all the other passing tests still pass), and then refactor your code to prepare it for the next tiny step. TDD is a design approach, and it helps users write better code, because testable code is written by default.

Continuous Integration (CI) In Continuous Integration you integrate the changes in the source code often. A build server then builds the whole branch, executes all unit tests and all acceptance tests, and spreads the information about this build to your colleagues. CI relies on an automated build, and it helps teams to see problems with the current state of the branch very early—not just one hour before the release shall be shipped.

How to Read This Book

In this book I provide a mixture of concrete practices alongside some of the principles that I found useful. There are multiple ways to read this book—depending on your experience level you may pick any of them.

You may read this book cover to cover. You will get to know more about Cucumber, Behavior-Driven Development and how to test webpages using an ATDD tool. The first example is also based on a team that differentiates between testing experts and programming experts. You will find collaboaration as one key success factor there.

In the second part I will pair up with you. By pairing up we can compensate for any missing testing or programming knowledge at this point. We will drive our application code using ATDD in a practical way. We will deal with FitNesse, a wiki-based acceptance test framework. The examples in the second part are covered in Java.

In the third part you will find some guidance on how to get started with the approach. I give pointers to further readings as well as hints on how to get started, what worked well, and what did not work so well for other teams.

In the appendixes you will find the two tools used in this book and even a third one explained in some depth to get you started. If you haven’t run into Cucumber or FitNesse, you may want to start there.

An advanced-level reader might skip the first two parts initially and directly start with the principles I explain in the third part. Maybe you want to provide some background to your colleagues later. The examples in Parts I and II serve this purpose.

You may also read the first two examples, and then head back to work to start a basic implementation. Once you reach a dead end, you may come back to read further material in Part III—although I wouldn’t necessarily recommend reading this book in this order.

If you already have an ATDD implementation in place on your team, you may want to dig deeper in Part II where I explain how to drive the domain code from your examples.

These are some ways in which I can imagine reading this book. If you’re like me, you’re probably thinking of following the examples by implementing the provided code on your own. I set up a github repository for each of the code examples. These allowed me to acceptance test the code examples on my own. If you find yourself stuck, you can have a peek there as well. You will find the examples for the first part at http://github.com/mgaertne/airport, and the sources for the second part at http://github.com/mgaertne/trafficlights.