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.