Acceptance Test Driven Development (ATDD): an Overview

By on December 8, 2008 in Uncategorized

“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.)

About ehendrickson

View all posts by ehendrickson →

Subscribe

Subscribe to our e-mail newsletter to receive updates.

Related Posts:

6 Responses to Acceptance Test Driven Development (ATDD): an Overview

  1. Pekka Klärck December 9, 2008 at 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

  2. Lisa Crispin December 17, 2008 at 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!

  3. Emmanuel Hugonnet January 23, 2009 at 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.

  4. Pekka Klärck January 28, 2009 at 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.

  5. Alessandro Collino January 29, 2009 at 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–

  6. Jimmy Vaughn September 17, 2009 at 1:35 pm #

    I found the article very interesting and informative. I have a few questions:

    What part do the tests executed using ATDD play in the overall testing of the product? Is there additional verification by a QA team and/or product owner?

    If there is no additional verification by an independent source (separate from development), doesn’t this introduce a risk where only development is testing the code? Your example seemed to indicate that the developer writes the unit tests and acceptance tests, as well as the code.

    Thank you.