TDD Kata: Bowling Game

A week into the bowling game, the time it's taken me to complete the exercise decreased quite a bit from the first time I did it.

Day 1: 60 minutes
Day 2: 45 minutes
Day 3: 30 minutes
Day 4: 26 minutes
Day 5: 15 minutes

Day one Even though I was mostly following Uncle Bob's example to write the tests and understand the kata; it took me about an hour on day one.
Day two I only had to reference the doc a couple times. Struggled a bit at seeing the refactors.
Day three I didn't look at anything but my TDD KATA sheet with what tests to write. Here I feel like I stumbled writing up the single strike. Previously this is the test where I'd turn it into the FrameStep; didn't need to... I was baffled. But wrote up the PerfectGame and BOOM. I actually had to do a significant chunk of refactoring here; and tests were flashing red/green (I like nCrunch).
Day four Took about 20 minutes today. I spent a few minutes looking at calculating the score in the pins method... shudder That'll be nightmares. I also started late so being social cost a couple minutes. Total time taken was 26 minutes; so... about 20 minus distractions. I didn't use the TDD Kata sheet, had the tests to write memorized. I did have to check how many rolls after a strike... I always want to to have 3 additional _g.pins(#) instead of 2.
Day five This is a special day; we're going to do a bit of obvious implementation practice; and not worry about each little step. I liked this flow until I thought I was done. I missed a test. It was obvious that I was done. I did everything I thought I should... missed a test; missed a refactor. The obvious solution isn't always going to get the code to the same place. The methodical nature of the TDD steps help the process to produce better code.
I then wanted to do an additional refactor to remove the if-ifelse-else chain that's been in each solution. I had tests; which let me know I took FAR FAR too big of steps. I took a few small ones to implement a delegate; test, next... Then I got a little over confident, did a bunch of steps; it broke. Then... sigh What'd I do wrong? I still had a pretty limited set of changes, but it wasn't A change which would have made it obvious. The Obvious Implementation can lead to non-obvious breaks.

Tomorrow I'll find a new TDD to do for a week.

Quinn Gil

Code Crafter beating the drum of Development Best Practices. Extreme Programming and Object Oriented Design.

Read More