TDD Katas / Exercises: Multimap (2 / 5+)

by Jeff Langr

May 08, 2019

The 2nd in series of blog posts in which I describe TDD katas & exercises that I’ve used for training purposes.

Multimap

A data structure that supports storing multiple values at a key. Think “English language dictionary,” which can contain multiple definitions for a single word.

  • key => [values]

  • You add to the multimap by specifying a key and a single value to be stored at that key: dictionary.put(‘a word’, ‘a definition’)    // or dictionary[‘a word’] = ‘a definition’

  • You retrieve from the multimap by specifying a key: var keys = dictionary[‘a word’] expect(keys).toEqual([‘1st definition’, ‘2nd definition’]

  • Answers its size (the number of keys)

  • Answers the total count of values stored across all keys (e.g. “count of all definitions”)

  • Answers whether or not it is empty

  • Throws / returns an error when attempting to store a null key

Duration: 45 minutes

Core themes:

  • Test ordering

  • Sticking with the R-G-R rhythm

  • Incrementally moving from specific to more generalized implementations

I used the Multimap as an introductory TDD exercise for a while many years ago. In turn working backward, this exercise replaced my use of test-driving a stack as an exercise; I moved off of that due to the negative feedback it garnered because of its over-simplicity (which appeared to help reinforce resistances to TDD).

Test-driving a multimap works well as a first exercise (or second exercise if the first was done using “TDD paint by numbers,” in which case you’d want to discuss a starter test list with the group). It does provide a couple opportunities for the students to create mildly interesting defects. It is “real” enough in that I’ve found a few occasions to use it in production code.

Note that some languages and / or frameworks (e.g. Guava for Java and C++11 / later) already provide a Multimap implementation. In this case, test-driving a multimap can still work as an exercise, though it could also provoke thoughts of “why are we wasting our time building something already readily available?”

Some possibilities for extra credit / extending the exercise.

  • Support adding multiple values at a key in addition to singular values

  • Provide the ability to find a key based on a predicate against the values

  • Support storing the values in a sorted order

  • Support storing only unique values for a single key

  • Support removing keys

  • Support removing a specific value

  • Support replacing a specific value

  • Support interesting iteration

** 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?

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+)

Share your comment

Jeff Langr

About the Author

Jeff Langr has been building software for 40 years and writing about it heavily for 20. You can find out more about Jeff, learn from the many helpful articles and books he's written, or read one of his 1000+ combined blog (including Agile in a Flash) and public posts.