The 1st in series of blog posts in which I describe TDD katas & exercises that I’ve used for training purposes.
When training on TDD, I agonize most about the exercises. Students should be challenged enough to remain engaged, but not so much that they mire in a problem solution, to the detriment of their learning important TDD concepts. I’ve written a few blog posts about what I thought made for a good exercise–not overly trivial, not too short, not too long, not too mathematical, etc.–as well as how to run the session for a very first TDD exercise:
-
Selecting a First TDD Exercise (a more detailed list of criteria than the previous article)
You’ll find piles of katas and coding exercises listed at numerous sites, including https://exercism.io, http://codekata.com, https://www.codewars.com, https://github.com/emilybache, and https://projecteuler.net/archives.
What would be nice is if every exercise came with training notes: information that would help you understand when and if it’s appropriate for your teaching context: how long will it take, what are the key themes the exercise helps impart, challenges to look for, and so on.
Over this and the next handful of blog posts, I’ll provide this information for some TDD exercises that I’ve devised.
The duration I suggest for each is roughly what it takes in a classroom setting where students are pairing. The duration can be impacted by a number of factors:
-
Is it their first TDD exercise or a subsequent one?
-
What’s their general level of programming proficiency?
-
What programming language is used? (C++ programmers, for example, will typically take longer than others)
-
Are they pairing, mobbing, or doing solo coding (not suggested)?
In the remainder of this post, I’ll describe the stock portfolio exercise.
In subsequent posts, I’ll cover: soundex, Risk card sets, name normalizer, MultiMap.
Stock Portfolio
An in-memory module to track personal stock purchases. The stories:
-
Answer whether or not it is empty.
-
Answer its count of unique symbols (e.g. “IBM,” “AAPL”).
-
Make a purchase, given a symbol and # of shares.
-
Answer how many shares exist for a given symbol.
-
Make a sale, given a symbol and # of shares.
-
Throw / return an error when attempting to sell too many shares.
Duration: 45-50 minutes
Core themes:
-
Writing the least possible code
-
Test ordering
-
Sticking with the R-G-R rhythm
-
Incrementally moving from specific to more generalized implementations
For me, this is usually the students’ second exercise; the prior is some form of TDD “paint by numbers” (where the tests were already written for them). Since they are writing their own tests for the first time, then, a core focus is on helping them understand where to start and what tests to write next.
Generally we talk through the first 5 or so tests as a group; I write these test names on the whiteboard and we discuss their potential implementation. It’s possible to write the first handful or so of tests–all of them around concepts of emptiness and symbol count–without having to introduce a key-value structure. (Even when they get around to the test that says the symbol count shouldn’t increase for a repeat purchase for a symbol, they can use a set before they need to introduce the key-value store.)
Students will likely come up with some additional validation test cases–negative numbers, nulls, etc. That’s ok though not very interesting. A key case to include and discuss is what the portfolio answers when asked for shares of a symbol not yet purchased (it should probably be 0). A test that not everyone will think of is what should happen to the count of unique symbols when all shares of a symbol have been sold.
One big plus of this exercise is that it supports many additional stories if needed. Here are two key ones:
-
List transaction history given certain criteria (or list all). Will require addition of a timestamp, and probably demonstrate that a key-value store might not be the best structure (time series, maybe?).
-
Calculate value of the portfolio (to help teach test doubles)
There are good opportunities for refactoring in this kata. Similarities between purchasing and selling should result in some useful common abstractions. Also, once the time series becomes a thing, it’s probably a good point to introduce another module / class.
Overall I’ve found that the stock portfolio exercise works very well. It provides enough opportunities for students to trip up, and starts to bang in the concept of incrementalism.
Related posts
Pingback: TDD Katas / Exercises: Stock Portfolio (1 / 5+)
Pingback: TDD Katas / Exercises: Multimap (2 / 5+)
Pingback: TDD Katas / Exercises: Name Normalizer (3 / 5+)
Pingback: DD Katas / Exercises: Soundex (4 / 5+)
Pingback: TDD Katas / Exercises: Risk Card Sets (5 / 5+)
Comments
Interesting walkthrough! Indeed, having trainer notes is a real time saver to run an effective coding dojo training. I might give your kata a try 🙂
It looks like we all have our preferred katas. Personally, I love doing the Mars Rover as a second dojo because it involves a bit of design and refactoring. I actually have a full plan I’m currently following to get teams up to speed with refactoring (https://philippe.bourgau.net/a-coding-dojo-exercises-plan-towards-refactoring-legacy-code/).
Thanks again.
