A quick guide to ATDD

I introduced ATDD (Acceptance Test Driven Development) to a team I was recently working with. It’s been used by agile teams for years (sometimes referred to as BDD — Behaviour Driven Development), but I do not see it used much in the wild nowadays. This is a massive shame because it is a simple yet powerful technique for building quality into a product.

ATDD involves:

• Having conversations with teammates and a customer about what behaviour is expected in the product, and describing that behaviour in what we call feature files (each feature represents a complete and useful piece of functionality)
• Specifying that behaviour inside the feature files in a written format which is readable by anyone, including clear end-user scenarios with real examples representing the desired functionality
• Turning those scenarios into code which represents automated executable tests — these wrap around the code the developers will write to make the functionality work

The automated tests will initially fail because no code has been written to make them pass! Once the code is written and the tests pass, we now all have confidence as a team that the product is behaving in the way it is supposed to for the customer. If we miss something, we can add new scenarios or update the existing ones, and the corresponding code can then be updated/added.

An added bonus is that each time we add a new test or update an existing one, we are also documenting the behaviour of the product’s features. This means that we all know at any given time exactly what the customer can accomplish with the product.

Not to mention that, because these tests must all pass before we release the software into production, the suite of tests represents the functionality that we KNOW WORKS! We can be confident that when we add new capability to the product, so long as all the acceptance tests pass, we have not created any regression bugs.