Tasks
The story as it stands is a little too big to tackle on its own, so typically it would be broken down into a set of tasks that enable us to complete the story. For this simple blackjack story the following tasks can be identified.

• Create a deck of cards
• Create a betting pot
• Create a hand of cards
• Create the game
• Create a deck of cards

As we break down a story into tasks, we can break a task down into a set of to-do items that will guide our tests. That gives us confidence that when all the tests pass, the task has been completed. For the deck of cards we have the following list of to-dos.

• Add a card to the deck
• Deal a card removing it from the deck
• Check if a deck is empty
• Check the number of cards in the deck
• Limit the deck to 52 cards (throw an exception if more are added)
• Cards are dealt last in last out
• Shuffle the cards in the deck
• Check that the added cards are a valid deck

After working through the first few simple tests our to-do list looks like this;

• Add a card to the deck
• Deal a card removing it from the deck
• Check if a deck is empty
• Check the number of cards in the deck
• Limit the deck to 52 cards (throw an exception if more are added)
• Cards are dealt last in last out
• Shuffle the cards in the deck
• Check that the added cards are a valid deck

The next test to tackle is dealing a card from the deck. When we write the code for the test method we are acting as a client of the implementation code we have yet to write. This is where we are designing what the interface to our class will look like to those that will have to use it. In this instance we're following the Command/Query Separation Principle⁵ and code the test as shown below.

Deck class. This is shown in Listing A.

Listing A

import java.util.List; import java.util.ArrayList; public class Deck { private static final int CARDS_IN_DECK = 52; private List cards = new ArrayList(); public boolean isEmpty() { return size() == 0; } public int size() { return cards.size(); } public void add(int card) throws IllegalStateException { if(CARDS_IN_DECK == size()) throw new IllegalStateException("Cannot add more than 52 cards"); cards.add(new Integer(card)); } public int top() { return ((Integer) cards.get(0)).intValue(); } public void remove() { cards.remove(0); } }

All our tests pass and we can't see any duplication or other necessary refactoring, so it should be time to move on the next test. Except that it isn't. Our implementation of the top and remove methods contain a potential problem. What happens if they are called on an empty Deck? Both methods will propagate an IndexOutOfBoundsException from the internal list of cards but we're not currently communicating this. Looking back at our rules for simplicity we see that we need to be communicative. Clients of our class should be made aware of the potential problem. Fortunately we have our tests as a means of communication and we add the following additional tests.