Quite often when we are running TDD workshops there are new people who come along to find out what it is all about and struggle to understand the why.
Some of the comments I most here are that the exercises we work through for the katas are “too simple”, or some of the decisions we make seem too arbitrary to be useful in real life programming.
For example when doing the string calculator example, from Roy Oshergrove’s site, a comment was made when someone wanted to introduce code and refactor the existing tests we had built up so they didn’t depend on “,” being the default separator and the general TDD advise was that we shouldn’t do this because it wasn’t part of the MVP as we knew it. The comment was around the usual lines of “but I’m an experienced software developer and I can see we might need it down the track in case someone removes the support for comma as the default operator”.
If someone decides to remove the support for comma as the default operator however, then this is a change to functionality that should cause a test to break somewhere and I am OK with this, but the one improvement that maybe we could make to the tests is refactor all of the logic for creating the input “string” into a common helper method that concatenated the list of numbers to be summed with the comma.
Anyway, moving on, most of the questions like this tend to come around because the problems and code we are solving for katas are small, and deliberately so as they are the kind of thing you want to sit down and practice for 10-20 minutes in the morning before you start for the day, or practice in a 1 hour session with a team. This makes them hard to relate to the real world of user stories and features.
One of the intuition pumps I encourage people to use when thinking about TDD with katas is try to relate each step of a kata to a feature or user story in the real world. When you scale things up in this manner, some of the decisions you make during a kata for a single “step” start to make a lot more sense if you imagine that “step” was a user story that was going to cost you a day or two of development.
So, if you are running TDD katas, or starting to practice them yourself, or if you are one of those people that like to ask questions like this when you attend a TDD workshop, just remember it really is like a karate kata, it really is about practicing things like Red,Green,Refactor, keyboard skills, thinking patterns, test naming and test design to name a few.
Challenge yourself to see the kata as a feature that is being developed over a number of sprints and each step being a user story or number of user stories that are worth days of developer time, rather than a single test or two during a kata.