Acceptance Test Driven Development (ATDD)

Posted by: James Golick on 2009-03-15

Test Driven Development (TDD) is this idea that you should write a unit test before you write the code. You run the test to make sure that it fails. Then, you implement the code necessary to make it pass. Rinse and repeat until the software is finished.

One of the most popular themes among TDD nay-sayers is the ad-absurdum argument. They don't know what they building. They're agile. So, how can they write their tests first?

As any test-driven developer knows, though, you don't write all your tests first. I know this. But, yet, when I first heard about ATDD, I, too, fell in to this fallacious trap.

So, what is ATDD?

It's rather simple, really. Before you implement a feature (or piece of a feature), you write an acceptance test. Then, you drop down to lower level tests (unit, functional) to TDD the code necessary to make the acceptance test go green.

I've only been ATDD'ing for a short while, but I'm already seeing a huge improvement in the quality of the stuff that I'm putting out. Much in the same way that unit testing can be looked at as a design practice for your code, ATDD can be looked at as a design practice for your high level functionality.

Starting with an acceptance test forces you to think at the level of the user before you think about your code. What is the workflow going to be? What should the user see? What buttons, fields, or other functional elements will be necessary and how will they be labeled? In my experience, these are often questions that are asked after the models and controllers (or equivalent units) are already built for that feature.

Answering those questions first seems to be a great way to better understand what you're building. Those are the only relevant issues in the eyes of your users. The answers to those questions are the application. Everything else, including the unit tests, is just the implementation.

Oh yeah, and a comprehensive set of acceptance tests is pretty useful too.