Acceptance TDD Explained - Part 3
2. Acceptance tests
Acceptance tests are specifications for the desired behavior and functionality of a system. They tell us, for a given user story, how the system handles certain conditions and inputs and with what kinds of outcomes. There are a number of properties that an acceptance test should exhibit; but before taking a closer look, let’s see an example.
2.1 Example tests for a story
Let’s consider the following example of a user story and see what our acceptance tests for that particular story might look like. I present you figure with 1.
Figure 1. Example of a user story, written on a story card
The functionality that we’re interested in is for the system to obtain and display the customer’s history of records when a call comes through the customer support system. I might, for example, think of the tests for this story that are scribbled down as figure 2.
These three tests would essentially tell us whether the system behaves correctly from the perspective of a user—conditions of satisfaction. They tell us nothing about how the system implements that behavior.
Now, with these example tests in mind, let’s look at some essential properties of acceptance tests, starting with who owns them and who writes them.
Figure 2. Example tests for the story, written on the back of the story card from figure 1
2.2 Properties of acceptance tests
So far, you’ve probably deduced that acceptance tests are typically short and somewhat informal. There’s more to the nature of acceptance tests, however, and next we’re going to look at some general properties.
To make a long story short, acceptance tests are
- Owned by the customer
- Written together with the customer, developer, and tester
- About the what and not the how
- Expressed in the language of the problem domain
- Concise, precise, and unambiguous
Let’s expand these sound bites one by one and see what they mean.