Acceptance Test Driven Development (ATDD) in Practice
On the testing front, the big theme at Agile 2009 seemed to be ATDD, or more specifically ATDD using the Robot Framework. Pekka Klärck (the creator of the Robot Framework) and Elisabeth Hendrickson (from whom I first heard of ATDD) did a great demo(y) session which did a better job of explaining both of things than watching screencasts or reading articles could do.
- Structure the requirements conversation so the outcome is a set of concrete acceptance tests
- A key characteristic of agile developers is confidence (we have the tests to prove it does what was wanted)
- Defining the product backlog results in shared understanding and a set of concrete, automatable tests
- Implement the ATDD tests at the same time as the production code (which itself is written in a TDD manner)
- Express tests in a natural language
- ATDD tools separate the driver of the interface from the expressions of intent
- Elisabeth types really well.
- Don’t capture “I don’t care” feelings from product owners in acceptance tests. They are not requirements. If they were, they would care.
- There are business facing expectations which need to be discussed. And there is all the other stuff around it that doesn’t.
- It is possible to have duplication of tests between the ATDD suite and the unit testing suite as they operate with different expectations and assumptions.
- 3 Pillars
- Automated unit tests
- Automated acceptance tests
- Exploratory testing built into the process
- Whiteboards and flipcharts are more productive for capturing requirements than any other product currently available.
- The Julia Child method of coding – have the code already written and just uncomment it
- ATDD emphasizes the interactions between people
Edit – It seems I got Pekka and his Robot Framework confused with Aslak and Cucumber. My sincere apologies; I’m still not back at 100% brain functionality and the ATDD tools are still just a big blob of ‘new toy’ in my brain.