Chapter 1. Prologue

“Begin at the beginning,” the King said, very gravely, “and go on till you come to the end; then stop.”

Lewis Carroll, Alice’s Adventures in Wonderland

Say hello to testable requirements. You are introduced to acceptance tests and discover the benefits of using them. You are also introduced to the team that will create them.

Ways to Develop Software

Different teams have different ways to develop software. Here are examples of two ways.

One Way

It’s the last day of the iteration. Tom, the tester, is checking the implementation that Debbie, the developer, handed over to him earlier that day. He goes through the screens, entering the test case data he created. He discovers that the results aren’t what he had assumed they should be. He’s unable to contact Cathy, the customer, for clarification as to whether he made the correct assumptions. There’s nothing left to do but write up a defect to be addressed during the next iteration, leaving less time to develop new features.

Another Way

It’s the last day of the iteration. Debbie, the developer, has run through the acceptance tests that Cathy, Debbie, and Tom created prior to Debbie starting implementation. Tom quickly runs through the same acceptance tests and then starts doing more testing to get a feeling for how the implementation fits into the entire workflow. At the review the next morning, Cathy agrees that the story is complete.

The Difference

What’s the difference between the first way and the second way? In the first case, no tests were created upfront. The developer had nothing to test against, so she relied on the tester to perform verification. The tester needed more details from the customer. Feedback as to success or failure of a requirement implementation was delayed. Every requirement story in the second situation has one or more tests associated with it, making each a testable requirement. The tests were developed by the customer, tester, and developer prior to implementation. As we will see in later chapters with detailed examples, these tests clarify the requirements. They provide a measure of doneness to all the parties.

If a requirement does not have a test, it is not yet demonstrated to be a testable requirement. If you cannot test that a requirement has been fulfilled, how do you know when it has been met? This does not mean that the test is easy to perform. Nor can tests be fully specified; there are always assumptions. But there must be at least an objective test so that the customer, developer, and tester have a common understanding of what meeting the requirement means.

The Importance of Acceptance Tests

In my classes, I often start with a dialogue to emphasize the importance of acceptance tests. It usually goes something like this:

I ask, “Does anyone want a fast car?”

Someone always says, “Yes, I want one.”

“I’ll build you one,” I reply. I turn around and work furiously for 5 seconds. I turn back around and show the student the results. “Here’s your car,” I state.

“Great,” the student answers.

“It’s really fast. It goes from 0 to 60 in less than 20 seconds,” I proudly explain.

“That’s not fast,” the student retorts.

“I thought it was fast. So give me a test for how fast you want the car to be,” I reply.

“0 to 60 in less than 4.5 seconds,” the student states.

I turn back around, again work quickly, and then face the student again. “Here it is: 0 to 60 in 4.5 seconds. Fast enough?” I ask.

“Yes,” the student answers.

“Oh, by the way: 60 is the top speed,” I state.

“That’s not fast,” the student retorts.

“So give me another test,” I ask.

“The top speed should be 150,” the student demands.

Again, I quickly create a new car. “Okay, here it is: 0 to 60 in 4.5 seconds. Top speed of 150. Fast enough?” I again ask.

“That should be good,” the student retorts.

“Oh, by the way: It takes two minutes to get to 150,” I let slide.

By this time, my point has been made. Getting just a requirement for a “fast car” is not sufficient for knowing what to build. The customer needs to create some tests for that requirement that clarify what exactly is meant by “fast.” Without those tests, the engineers may go off and create something that they think meets the requirement. When they deliver it to the customer, the customer has a negative reaction to the creation. The item does not meet his needs, as he thought he had clearly stated in saying, “the car must be fast.”

Having acceptance tests for a requirement gives developers a definitive standard against which to measure their implementation. If the implementation does not meet the tests, they do not have to bother the customer with something that is noncompliant. If each acceptance test represents a similar effort in creating the implementation, the number of passing tests can be used as a rough indication of how much progress has been made on a project.

I’d like to clarify a couple of terms that are used throughout the book: acceptance criteria and acceptance tests. Acceptance criteria are general conditions of acceptance without giving specifics. For the car example, these might be “acceleration from one speed to another,” “top speed,” and “must feel fast.” Acceptance tests are specific conditions of acceptance, such as “0 to 60 in less than 4.5 seconds.” Each acceptance test has unstated conditions. For example, an unstated condition could be that the acceleration is measured on a flat area, with little wind. You could be very specific about these conditions: an area that has less than .1 degree of slope and wind less than 1 mile per hour. If necessary for regulatory or other purposes, you could add these to the test. But you should avoid making the test a complex document.

A few facets that differentiate acceptance tests from other types of tests, such as unit tests, are

• The customer understands and specifies acceptance tests.

• Acceptance tests do not change even if the implementation changes.

System and Team Introduction

The principles and practices of acceptance test-driven development (ATDD) are introduced through the tale of the development of a software system. The story originated in my book Prefactoring—Extreme Abstraction, Extreme Separation, Extreme Readability [Pugh02]. That book emphasizes how developers can create a high-quality solution for the system. This book highlights the customer-developer-tester interaction in creating and using acceptance tests in developing the system.

The System

Sam, the owner of Sam’s Lawn Mower Repair and CD Rental Store, had a lawn mower repair shop for a number of years. He noticed that people coming into the shop had circular devices hanging on their bodies. It turned out they were Sony Discmans. Being the inquisitive type, he discovered that his customers liked to listen to music while they mowed the lawn. So he added CD rental to the services his store offered.

Business has been booming, even though the Sony Discman is no longer being used. People are now coming in with little rectangular boxes hanging around their necks or sitting in their pockets. They are renting more CDs than ever and returning them quickly—in as little as an hour. Sam’s paper system is having a hard time keeping up, and it is becoming difficult to produce the reports needed to track the inventory. Sam is planning to open a second store. Before he does that, he figures that he needs to obtain a software system, or his issues will just double.

Sam got a recommendation and called Debbie. She works with Tom in an agile development shop. Sam selected that shop to develop the system.

The People

Sam represents the project sponsor for the new system. His wife Cathy takes care of the logistic side of the business. She does the bookkeeping, handles the inventory, and places orders for new CDs. Cathy plays the role of customer—the one requesting the application. Along the way, as you’ll see, Cathy is introduced to software development and in particular to ATDD. Other interested parties include Sam’s sister Mary and his brother-in-law Harry, who frequently help out at the store. Their son Cary is a clerk at the store. He will be using the new system.

Debbie is the developer and Tom is the tester. They work as a pair to understand and implement what Cathy needs. The terms developer and tester are often related to titles. In this book, these terms refer to what Debbie and Tom focus on. The development focus is to create an implementation that does what it is supposed to do. The testing focus is to check that the implementation does precisely that and does not do what it should not.

Focus may not be correlated with the titles developer and tester. In many agile processes, such as Scrum, there are no titles on teams [Larman01]. Any two people may pair together, with one focusing on testing and one on implementing. It’s possible that a single person may focus both ways on a particular requirement. The entire team is shown in Figure 1.1.

Figure 1.1. The Team

Summary

• A testable requirement has one or more acceptance tests.

• An acceptance test is a standard to measure the correctness of the implementation.

• Acceptance tests are created in collaboration with the customer.