Category: Dojo

Posted on

Bowling Kata “solution”

One of the most famous katas (excercises) for TDD (test-driven development) is the Bowling Kata. There are some sites that describe the Kata, which has the following “stories” as input:

  • A bowling machine want to report the number of pins the player strikes down for every roll the player does
  • A bowling player want to see the resulting score of a completed game

It is actually a rather simple Kata, but never the less allows for demonstration and training of some TDD tasks and strategies. But of course you need to know the bowling rules…

We have used the Bowling Kata for our Coder’s Dojos, and have learned a lot from it. The following is a recording of one of my solution to it :

Posted on

Refactoring with red bar?!?!?

We have been running the Coder´s Dojo Sweden during the autumn, and yesterday we started the spring sessions. One of the interesting observations that we have made is a follow-up on a comment that I made on Robert C. Martins page about the Bowling Kata.
The observation was that if you follow the rules “refactor only in the green” (you may only refactor while you have working and passing tests as your life-west) and “only develop new functionality in the red” (while you have a failing test for that functionality), you will inevitably end up with a situation that your new functionality driving test case forces a re-design, right?
It may be obvious to most of you out there, but we couldn’t find a single mention of how you are supposed to solve that predicament. We surely do not want to do a redesign with a failing test, the green bar is our safety net. Of course you could keep an eye on which tests are causing the red, but that is tedious and error-prone.
What seems logical is to temporarily get rid of the failing test, which you can easily do by commenting out the failing test. Simple, right? And possibly second nature to seasoned TDD:ers. But if so, why has there been no developmen of tools support for this? I could easy envision a “disable test” feature in the Eclipse/JUnit GUI…

Posted on

Fifth Dojo, and still learning…

Today we ran the fifth Coder’s Dojo. Still the same Bowling Kata in Java and Eclipse (oh, I love that IDE!). This time we where only four, which allowed each of us a lot more driving time, which was fun.

This time we managed to get through the whole Kata, and even found some time to discuss one of the issues bothering some of the participants already from the start, namely error checking. Andreas and I went down that path while on the flight from the Agile Business Conference 2006 and had some learning to share. The main point being that error checking, like checking for score() being called before the game is finished (remember, the user stories actually calls for the game being finished) has to be made explicit, obviously driven by a user story (the user in this case being what ever actor is interested in such a message).

But, the most interesting thing was that we where very explicit about doing a refactoring to get a design which is better suited to fit new functionality into. I think we actually made a few steps better than Uncle Bob’s original. That feels nice 😉

Posted on

Coder’s Dojo Sweden is open!

Yesterday Andreas Larsson and myself hosted the first ever Coder’s Dojo in Sweden. If you have never heard about it before you can visit its home page and explore more.

It was an interesting experience. Having run through the Bowling Kata a number of times, both together and by ourselves, we still found that discussing with people was a learning experience since many of the attendees did not have the experience we did. And as always, talking about something forces you to be clear in a way you don’t need to otherwise.

My personal insight with the Kata the way we played it out (inspired by Uncle Bob’s presentation of it) was how strong the urge to create new classes is in all of us. Andreas and I fell into that same hole when we did the Kata in Oulu the night before XP2006.

I also discovered that I had insights that I where not aware of with regards to the brittleness of testcases; that you should be careful to test the intended behaviour, and not the design. E.g. when doing the first test case for the Bowling Kata, don’t test that the score of the created (presumed empty) game is zero. That’s implementation! The required behaviour (and the only thing that should be tested) is that calculating the score, after all the rolls of the game, should give the correct result.

And of course, you can find a lot of thinking on the BDD (Behaviour Driven Development) on the web.