Acceptance Test-Driven Development: Not as Optional as You Think

[article]
Summary:
The components of software processes work together in important and sometimes unrecognized ways. The removal of one of those components will affect the others. In this article, which originally appeared in the August 2010 issue of the Iterations eNewsletter, Jennitta Andrea takes a look at the value of acceptance test-driven development and the costs of making it an optional practice.

As a practitioner, I prefer to define agile by its visible outcome, rather than focusing on the collection of practices performed by a team. I define agile as: "delivering running tested features to the user community on a regular basis to maximize business value and to respond to timely feedback with strategic product adaptation." [1] I believe it's healthy for different agile projects to make different decisions about their practices, as long as the outcome is achieved and sustained. Successful projects understand that project context (criticality, complexity, duration, team composition, etc.) is key to making good decisions about their agile process.

That said, it concerns me that far too many teams treat the acceptance test-driven development (ATDD) practice as optional.

What Is ATDD?
ATDD (a.k.a. story test-driven development, functional test-driven development, behavior-driven development, etc.) is the practice of expressing functional story requirements as concrete examples or expectations prior to story development. During story development, a collaborative workflow occurs in which: examples are written and then automated; granular automated unit tests are developed; and the system code is written and integrated with the rest of the running, tested software. The story is "done"deemed ready for exploratory and other testingwhen these scope-defining automated checks pass. [2]

Why Should We Practice ATDD?
Software processes are like an ecosystem; all of the componentsactivities, practices, roles, workflows, tempo, tools, and work productsdepend upon and enable each other in complex and unexpected ways.

ATDD enables:
Trustworthy specifications: ATDD requirements specifications are trusted because they are concrete, thus bringing areas of ambiguity and inconsistency to light very early. They are living (automated) documents that will not get out of sync with the code. Whenever the code is changed, immediate feedback is provided about mismatches between the two. This level of trust exists for the lifetime of the system, facilitating the transition to operational support for maintenance and enhancements.

Short iterations: Given the above definition, the key to an agile project is incrementally building the system, feature by feature. Everything-requirements, design, development, integration, testing, and review-is condensed in order to fit an entire cycle into a short, fixed-sized iteration (typically two weeks). ATDD helps the team maintain a concrete, clear focus and provides an unambiguous definition of what "done" means for each piece of work in the iteration.

Incremental development: Working incrementally means different people will revisit and integrate the same code many times. This approach is not practical unless there is a safety net of automated checks to ensure unintended side effects have not been introduced. ATDD builds such a safety net at both the business- and technology-facing levels. [3]

Enriched tester role: In the early days of agile, it was thought that ATDD would make testers obsolete. Early agile projects found out the hard way that the tester role is needed more than ever. Ironically ATDD makes the tester role much more enriched and valuable. Automated examples and unit tests take care of the "checking," guaranteeing a stable system for the testers to perform their creative, skilled, and value-added work of "testing." [4]

Highly testable system: ATDD produces a highly testable system. Having examples and unit tests drive development ensures that the system can be accessed and validated from any possible angle, facilitating future automation as well as manual testing and operational diagnosis.

About the author

Jennitta Andrea's picture Jennitta Andrea

Since 1988 Jennitta Andrea has been a keen observer of teams and processes while engaged as a multi-faceted hands-on coach and practitioner (analyst, tester, developer, leader). She worked on her first agile project in 2000 and has since been involved in a wide variety of agile projects. Jennitta's writing and teaching effectively bridge theory, practice, and her observations. She has published numerous experience-based papers. Her practical, simulation-based tutorials and in-house training cover agile requirements, process adaptation, automated examples, and project retrospectives. Jennitta's work has culminated in international recognition as a thought leader in the agile community. Details at www.theandreagroup.ca.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Aug 25
Aug 26
Sep 22
Oct 12