Logo Elisabeth Hendrickson’s Thoughts on Testing, Agile, and Agile Testing

Acceptance Test Driven Development (ATDD): an Overview

December 8th, 2008
Filed under Agile

“Begin with the end in mind.” — Stephen R. Covey

Acceptance Test Driven Development (ATDD) is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins. It’s the best way I know to ensure that we all have the same shared understanding of what it is we’re actually building. It’s also the best way I know to ensure we have a shared definition of Done.

Obviously I think this is an important Agile development practice. In fact, it’s one of the core pieces of my Agile Testing class. Yet somehow I have neglected to write about it much on this blog. Time to rectify that.

So, for your reading pleasure, I now present a PDF document with a detailed example of the whole ATDD flow.

Enjoy! (Comments/questions welcome.)

5 Comments

Pekka Klärck
Dec 09, 2008
2:39 am

First of all thanks for Elisabeth about publishing this great article. There isn’t that much material available about ATDD yet and I’m sure I’ll point many people to this one.

Those of the readers who got interested enough Robot Framework can find more information from http://robotframework.org. You would probably find especially the Quick Start Guide (link below) interesting because it is based on the same demo that is used in this article. You can effectively execute the tests presented in the article hands-on.

http://code.google.com/p/robotframework/wiki/QuickStartGuide

 
Lisa Crispin
Dec 17, 2008
12:47 pm

I absolutely love the way you’ve explained this so clearly both with graphical diagrams and easily understood examples. ATDD in a nutshell - I will be referring people here!

 
Emmanuel Hugonnet
Jan 23, 2009
2:30 am

Hi,
Great article and great diagram :o)
I would like to ask your opinion on how ATDD could be compared to Dave Nicolett’s TDR/FTDD and Dan North’s BDD. When I look at JBehave 2.x I see a story written as a group of scenarios that define the behaviour to be implemented which looks quite similar to ATDD.
Emmanuel

Elisabeth responds:
Thanks!

As for differences between ATDD and TDR, FTDD, BDD, and STDD, I think we’re all talking about more or less the same thing just using different names. And honestly, I don’t have a strong attachment to any particular name. I do, however, have a strong attachment to some subtle elements of the technique as I describe it. To me, the essential characteristics of ATDD, by whatever name you want to call it, are:

  1. We use test ideas to elicit details from the business stakeholder(s) about their expectations. By proactively discussing test ideas - like boundary conditions or configurations or varying sequences of user actions, etc - we can come to a shared understanding of the business stakeholder’s real expectations for the system instead of having testers file a whole bunch of bugs late in the process.
  2. We distill acceptance criteria into automatable tests expressed in a natural language rather than a programming language. This enables us to completely separate the articulation of expectations from any technical details or dependencies.
  3. We write fixtures or libraries to wire the keywords in the tests to the software under development during implementation. That’s wiring, not translating. And doing it as part of the implementation effort, not attempting to retrofit automation after the code is written.

 
Pekka Klärck
Jan 28, 2009
5:50 pm

I don’t know about TDR/FTDD (my google-fu fails me) but BDD is just one way to do ATDD. Notice that ATDD may also be called Story Test Driven Development, Executable Requirements, etc.

 
Alessandro Collino
Jan 29, 2009
2:59 am

Hi Elisabeth,

Excellent article!!!

In this post I want to analyze very briefly a pratical experience related to the usefulness of ATDD practice.

Let’s consider the case of an Agile project where the teams are distributed in an international scenario: I will refer here to this as an “offshore Agile project”.

Of course, the ATDD practice is a good practice in many contexts and so onsite it can be applied successfully.
But in my experience this practice could be a key practice in offshore Agile projects.

In fact in an offshore project in addition to try to communicate the requirements in the best way is of primary importance to define some good Acceptance Tests: this kind of tests helps to understand much better the requirements and/or the design to be implemented for two main reasons:

• Them help to avoid misunderstandings that usually arise from the only information provided by the requirements (in fact we have to consider many issues related to the offshoring: language, cultural differences, technology quality of the communication, and so forth)
• Them represent a “concrete goal” for the offshore developers

The Acceptance tests in this scenario, favour the adoption of ATDD, absolutely in a natural way.

–Alessandro–

 

Leave a Comment

Because of the rise in blog-spam, I've turned on comment moderation. If it takes a while before your comment appears, I hope you understand.

Moderation Policy: I approve substantive comments. I reject ads. And if I don't know whether it's substantive or advertising, it sits in my moderation queue until I get sick of looking at it, at which point I reject it, kind of like the questionable meatloaf in the fridge. But please be assured that I think long and hard before clicking that reject link. I really am grateful for every comment any human takes the time to make. (Spambots, not so much. But if you're reading this, you're probably human.) So please contribute to the conversation...