I’m an avid TDD’er. I just love it. I teach it a lot. To those who think they know and to beginners. And it is not so easy to grook. And maybe it’s an acquired taste. I feel it is an essential tool in a programmers tricks, and am amazed that so few actually know it well enough. And that there are still those that actively denounce it. It is not universally applicable, true, but in my mind, if you consider yourself a programmer, you must know how to do it fluently. Period.
In a few installments I plan on showing the way I do it. And possibly allow a few others to acquire the taste, and some proficiency. Maybe even some more seasoned coders out there will pick up some tricks. Or teach me some…
For me TDD is very much about three words: focus, confidence and pace.
TDD done right allows, and forces, you to focus. We all know that focus is key to progress. But also that you usually only manage to focus on smaller, clear, things. Big, fuzzy things are hard to pinpoint, to focus on and of course, to get any progress on. So the first step to TDD is partitioning into smaller chunks.
Let’s get started. You have probably read, or heard, that the first thing that you should do is write a test.
Wrong.
The first thing you need to do is to understand the problem so that you can list at least two or three tests. And what tests might that be?
I think this is the hardest part to learn. What are the tests? Which one should I start with? I view the tests as my tool, my hammer, that I use to attack the problem, or the parts of my code that needs to be refined. But we’ll see more about that later.
Let’s start with an example. To become proficient you need to practice and Dave Thomas introduced the notion of code katas, an analogue of the martial arts practice of repeating the same moves over and over until they where fully automated and internalized. I have done this often, and still do. Like I practice my typing skills, if not regularly, so repeatedly, I repeatedly re-try one of my favourite code katas. It’s actually quite fun. And you learn a lot.
I’ve selected the Texas Hold’em kata for this little series, and this time I’ll do it right.
So, before writing the first test we want to list a few relevant cases. There are some obvious ones:
- A player with a Pair wins over a player with High Card
- A player with Three Of A Kind wins over a player with a Pair
and so on. At this stage I always look for an “origo” case. What is the simplest test? Is there a starting point that we can use?
In the Bowling kata the “origo” case is obviously the “Gutter Game” (every roll in the gutter) resulting in a total score of 0. It’s easy to implement, should always be true whatever extra features we implement. The origo, or starting, case is important because it drives the initial API, infrastructure and other trivia, so we can focus on that first.
What’s the equivalent for the Texas Hold’em kata?