Acceptance Test Driven Development (ATDD) is a very effective development practice that essentially involves writing specifications in the form of documented and automated examples. These automated examples become automated acceptance tests that validate the features being delivered. The process of writing these examples encourages teams to focus on where the business value of a feature is coming from, which in turn helps developers aim for the most appropriate solutions in business terms.
When I help folks out with ATDD and TDD practices, one common question people ask me is this: Does using ATDD cost more in development time?
My gut feeling is that when you practice Acceptance Test Driven Development, developers spend maybe 20% extra time writing automated tests, compared to a project with no automated testing at all As far as TDD goes, I generally find that overall an experienced TDD practitioner will take similar or slighly less time to implement code using TDD than without using TDD.
However, that is far from the whole picture. Anecdotal evidence, and my own experience, suggest significant other advantages in adopting ATDD practices, and in fact projects using ATDD tend to deliver faster and with significantly fewer defectsthan projects using more conventional approaches. For example:
- Writing specifications in the form of automated tests helps clarify the requirements earlier rather than later, and ATDD-style reporting also makes it very visible what is actully being delivered. This helps keep development efforts focused on building features that will provide real value, which in turn reduces waste.
- Code written using TDD (especially using a BDD-style approach) not only has fewer bugs, but it tends to be much easier to understand and maintain, which makes changes easier (and less scary) to implement, and makes ongoing maintenance cheaper.
Automated Acceptance and Regression Testing (where automated tests are written after the features are delivered, but the tests do not play a driving role in the development process) are a great way to improve code quality and reduce the risk of embarrassing regressions and outages. However automated tests by themselves do not help focus and validate the development efforts the way ATDD does.
A recent study seems to confirm this. In this very interesting study, teams using agile development practices including in particular ATDD and TDD delivered projects 31% faster with 4 times fewer defects. Another study,