It seems like everyone is suddenly talking about Acceptance Test Driven Development (ATDD) these days.
I have worked with several organizations as they’ve adopted the practice. And I’ve watched each struggle with some dimension or another of it. The concept behind the practice is so simple: begin with the end in mind. But in order to gain traction and provide value, ATDD requires massive, fundamental changes from the traditional organization mindset where testers test, developers develop, product managers or business analysts write requirements documents, and each role works in its own little silo.
As one person said to me, “ATDD is moving some people’s cheese really hard.”
Sometimes when organizations contact me about helping them with ATDD, they start by talking about tools. They tell me they’ve selected a tool to do ATDD, or that they want me to help them with tool selection. They’re suffering from delayed feedback and slow manual regression cycles and they want to do ATDD because they see it as a path to automated acceptance tests. They think ATDD stands for “Automated Test During Development.”
What they don’t see is that ATDD is a holistic practice that requires the collaboration of the whole team. We collaborate on the front end by working together to define examples with expectations for stories, then articulate those examples in the form of tests. On the back end, when the team implements the story, testers and developers collaborate on connecting the tests to the emerging software so they become automated.
Handoffs don’t work with ATDD. The product owners don’t establish examples with expectations unilaterally; they work with developers and testers. The testers don’t create the tests unilaterally; they work with the product owner and developers. And when the team is ready to hook those tests up to the emerging software, there is no automation specialist just waiting to churn out reams of scripts. Instead, testers and developers collaborate to create the test automation code that mades the acceptance tests executable.
Starting an adoption of ATDD with the tools is like building an arch from the top. It doesn’t work.
The tools that support ATDD—Fitnesse, Cucumber, Robot Framework, and the like—tie everything together. But before the organization is ready for the tools, they need the foundation. They need to be practicing collaborative requirements elicitation and test definition. And they need at a bare minimum to be doing automated unit testing and have a continuous automated build system that executes those tests.
It’s best if the engineering practices include full-on Continuous Integration, Collective Code Ownership, Pairing, and TDD. These practices support the kind of technical work involved with automating the acceptance tests. Further, they show that the team is already heavily test-infected and are likely to value the feedback that automated acceptance tests can provide.