The 5th in series of blog posts in which I describe TDD katas & exercises that I’ve used for training purposes.
Other posts in the series:
Risk Card Sets
The venerable game of Risk™ has been around for over 60 years. It is a board game focused on international conflict. The tools of conflict? Little plastic armies, cards and dice. Players roll dice to determine conflict outcomes. They also collect and redeem sets of cards to gain additional armies.
The Risk Card Set kata involves building code to determine if the cards collected by an individual player represent a complete set. The criteria for what makes a valid set is defined by a few simple rules around the types of cards involved.
I wrote up the Risk Card Set kata a couple years ago after seeing an implementation (in a real, production version of the game) that bewildered me. The implementation was about five times longer than the code needed to be.
This kata is split into two parts. The first part drives in code to support the question, “do these three cards represent a valid set?” The second part of the kata adds a small nuance: “within this collection of one-through-five-or-more cards, are there any combinations that represent a valid set?” The two-part nature of the kata allows for some discussion of incrementalism in TDD.
Rather than me re-detail the original blog post here, please jump over to the original post. Within you’ll find all of the rules for the kata, as well as a number of questions intended to trigger discussion.
I’ve only used this kata a couple times in a learning setting, and with seasoned developers in both. They finished it reasonably quickly–in under 25 minutes each time.
The time to implement varies dramatically between people using high order array functions and those using rote, old school loop-based solutions: Even in a fairly verbose language like Java, my more-functional solution was only 8 statements (one constructor and 7 methods, each only one line of code). A tight old school solution is going to be at least twice as long.
I’ve kept this kata out of my TDD training for the time being, mostly out of concern that the results (how much people struggle, how long will they take) seem like they’re going to be wildly inconsistent. It also goes against my notion to not involve games in first-day TDD, lest people dismiss the exercise as too much of a “toy” problem.
Still, it remains a fun kata that can be a quick-hit exercise.
** For pairing TDD novices. Impacts to duration can include:
- Whether it’s their first TDD exercise or a subsequent one
- General level of programming proficiency
- Programming language used
- Exercise learning mode: pairing, mobbing, or solo?