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.
Hi, I'd love to hear/read more about TDD
And i think when deferring decisions about object creation in your last para is so simple, realistic and important. While creating a class is straightforward, coming up with the right API is challenging, especially when the core complexity lies in the algorithm. I prefer addressing the most risky elements first, then turning to the enjoyable task of crafting a succinct and effective API and often its not easy. Requires a different mindset from the one used in algorithm problem-solving, aiming to develop an API that is simple, clear, and user-friendly.
Maybe its easy for a like a stack, but it generally holds true.
I like these little thoughts that open your eyes to a completely different perspective. Shuffling the order of decisions, creating the object as late as possible, experimenting with the algorithm just inside the tests — really cool exercise, thanks a lot!