Learn About Agile Project Management and Scrum

Card, Conversation, Confirmation

We mentioned in the last chapter that:

1. User stories are simple versions of requirements and short enough to be written on a sticky note or an index card.

2. Since the user story does not contain all of the detailed information necessary to start work on it, the next step is to speak with the team (perhaps during a planning session) to discuss details before implementing a solution.

3. The additional details from these conversations allow you to make decisions as a team and determine which rules (i.e., which tests) represent the desired implementation of this feature. Writing these details down enables confirmation later on when the feature is built and ready to be tested. Specify up front what has to work (what tests it should pass) or this feature to be acceptable. For this reason, these additional scenarios are often called acceptance tests.

Writing Acceptance Tests

When writing acceptance tests, think of some examples of how the system should behave. Take the following three examples of how an ATM machine might work:

1. If the customer tries to withdraw $20 and her account balance is over $20, then allow the withdrawal and reduce the account balance by $20.

2. If the customer tries to withdraw $20 but her account balance is under $20, then do not allow the withdrawal.

3. If the customer tries to withdraw $300, then do not authorize the withdrawal and show the message: "maximum withdrawal is $200." 

Write this set of examples in the Given-When-Then format:

• Given: A set of initial circumstances (e.g., bank balance).

• When: Some event happens (e.g., customer attempts a withdrawal).

• Then: The expected result as per the defined behavior of the system. 

Note the following benefits of using the Given-When-Then format:

• It is easy to see the set of initial conditions, the event, and the outcome. 

• This makes it easy to understand and easy to test.

Look at the first example from above:

If the customer tries to withdraw $20 and her account balance is over $20, then allow the withdrawal and reduce the account balance by $20.

Writing that in Given-When-Then format will look like this:

Using Examples

Note that the "User balance = $23."

You might be asking yourself, "Why did he pick $23 and not $24?" The answer: it doesn't matter. The acceptance test would have been just as good using other numerical examples.

Sometimes, the rule is also written as part of the acceptance test.

The two examples of withdrawing $20 (one with a $23 balance and one with an $18 balance) are part of the same rule. Look at the second example:

Now look at the daily withdrawal limit example and write it in Given-When-Then format:

Putting it all together, you would end up with something like this:

Now imagine that you are a new developer on the team, and you missed the planning session last week. But someone shares these acceptance tests with you. Ask yourself the following questions:

• Are these acceptance tests easy to understand?

• Did they take a long time to read?

• Does having the example and the rule help?

• Do you think you would know what to build?

Most people would answer "yes" to all these questions - with the exception of "Did they take a long time to read?"

Let’s Recap!

• Acceptance tests are a way of confirming that a user story was implemented correctly.

• Acceptance tests always follow the Given-When-Then format.

• Think of acceptance tests as scenarios or examples.

• Include the "rule" and a set of related acceptance tests for additional clarity. Then you can easily see the rule and examples (acceptance tests) that illustrate the rule. 

Acceptance tests are super important! In the next chapter, you'll see how to create a definition of "Done".