Does ATDD really save you time?

Details

Jan20

Written by Super User

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, back in 2008 found that using TDD reduced defects by between 40% and 90%, although it increased initial development time by 15-35%. The teams did agree however that this increase was offset by lower maintenance costs.

And yet another, from 2006, found that TDD significant improvements in the quality of the code (in terms of the defect rate), but were inconclusive with regards to productivity gains.

These studies are certainly very interesting. However I think that the earlier ones actually tend to understate the advantages of TDD, for two reasons:

• They are often done with teams that were realtively new to TDD practices: However like many practices, TDD works better when you have already had some practice. In my experience, time spen
• They do not factor in the time gains in the maintenance phase: indeed, anyone with any experience using TDD will confirm that code written using good TDD practices is significantly easier to understand and maintain.

Modern development practices such as ATDD and TDD are not easy: they require significant efforts in championing, training, mentoring, and managerial support. However there is little doubt that, when well applied, these techniques significantly improve code quality and reduce maintenance costs, but can also contribute to faster project delivery and thus reduced project costs.

atdd

bdd