Stretching Your TDD Skills

I swear I never intended to publish a bunch more on TDD. But here we are. This is one from the archives, first published November 2010. It’s for TDDers who want to stretch their skills. In Tidy First? land we talk about the Succession Problem—in what order do we make decisions? The more, different orders you can manage, the more options you have for:

• Realizing value sooner

• Deferring investment without dramatically increasing cost

• Side-stepping “blockers”

What follows is an exercise intended to stretch your ability to take decisions in many different sequences.

As part of a recent advanced TDD course, we took a careful look at a simple stack implementation TDD-style. Here are the decisions that went into designing and implementing the stack. First, the specification decisions:

• Stack is an object

• Name is “Stack”

• There is an operation to add an element

• It is called “push”

• It takes a parameter

• The type of the parameter is the same as the type of the stack

• Stack has a type parameter

• There is an operation to remove elements

• Its name is “pop”

• Its return value is the same as the type of the stack

• Elements are ordered LIFO

Here are the implementation decisions:

• Store the elements in a List

• Type of the list is the same as the type of the stack

• Implementation type is ArrayList

• Add/remove elements at the beginning of the list

Here’s the exercise: start with any decision above & TDD, then another, and another. Pay attention to how frequently you can reach a green test. Pay attention to which sequences of decisions actually make sense.

What we found was that of the 15! [ed: 1,307,674,368,000] permutations of decisions, many of them worked just fine and could be used for different purposes.

One of the fun variants I remember is putting off making an object as long as possible. The first few test cases had snippets of code for push & pop just inline. This is the kind of sequence that most folks would never consider, but that can be valuable when e.g. you want to explore an algorithm without committing (even temporarily) to an API.