Acceptance TDD Explained
This article is based on a chapter from the book "Practical TDD and Acceptance TDD for Java Developers",
http://www.manning.com/koskela/, published in October 2007. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book's page for more information. © 2007 Manning Publications Co
In the spacecraft business no design can survive the review process, without first answering the question—how are we going to test this thing?
—Glen B. Alleman, Director Strategic Consulting for Lewis & Fowler
In the previous chapters, we have explored the developer-oriented practice of test-driven development, covering the fundamental process itself as well as a host of techniques for employing TDD on a variety of Java technologies. In this chapter, we’ll take the core idea of TDD and apply it to the overall product development process.
TDD helps software developers produce working, high-quality code that’s maintainable and, most of all, reliable. Our customers are rarely, however, interested in buying code. Our customers want software that helps them to be more productive, make more money, maintain or improve operational capability, take over a market, and so forth. This is what we need to deliver with our software—functionality to support business function or market needs. Acceptance test-driven development (acceptance TDD) is what helps developers build high-quality software that fulfills the business’s needs as reliably as TDD helps ensure the software’s technical quality.
Acceptance TDD helps coordinate software projects in a way that helps us deliver exactly what the customer wants when they want it, and that doesn’t let us implement the required functionality only half way. In this chapter, we will learn what acceptance test-driven development is, why we should consider doing it, what these mysterious acceptance tests are, and how acceptance TDD integrates with TDD.
Acceptance test-driven development as a name sounds similar to test-driven development, doesn’t it? So, what’s the difference between the two? Surely it has something to do with the word acceptance prefixed onto TDD, but is there something else beneath the surface that differentiates the two techniques? What exactly are these acceptance tests? And what are we accepting with our tests in the first place? These are the questions we’re going to find answers to as we start our journey into the world of acceptance tests and acceptance test-driven development.
We’ll begin by describing a lightweight and extremely flexible requirements format called user stories. After all, we need to know how our system should behave, and that’s exactly what user stories tell us. From there, we’ll continue by exploring what acceptance tests are and what kinds of properties they should exhibit. By then, we will know what our requirements—the user stories—might look like, and we will know how our acceptance tests should look, which means we’ll be ready to figure out how we work with these artifacts or what the process of acceptance TDD looks like.
An essential property of acceptance TDD is that it’s a team activity and a team process, which is why we’ll also discuss team-related topics such as the roles involved and who might occupy these roles. We’ll also ask ourselves why we should do this and respond by identifying a number of benefits of acceptance TDD. Finally, we’ll talk about what exactly we are testing with our acceptance tests and what kind of tools we have at our disposal.
But now, let us introduce ourselves with a handy requirements format we call user stories.