The Quest for Great Software

I was very happy to take part in the coding dojo of 8 February 2006. The previous time I had attended was the first public session Helsinki in November, and compared to that, the recent dojo went considerably more smoothly:

• the cooking stopwatch worked excellently for keeping each person’s turn at ten minutes, with one of the pair rotating every five minutes. (My personal goal for the next dojo is to learn how to set up the watch correctly ;))
• the audience kept moderately quiet, and the questions were less suggestive than before — i.e. more questions, less directions

And again, I learned valuable things on how other people mould the code, think about the micro-level design, and write tests.

The word “tests” just above should disturb you, if you think that we are practising Test-Driven Development (TDD) in the dojos.

In the randori-style dojo, as a pair produces code, everybody watches it on the projected screen. Sometimes the audience gives slight signals of appraisal, especially when a pair successfully completes a feature, runs the tests, and the xUnit bar turns green. I wanted to cheer not only for the green but also for the red bars. People found this strange, which bothered me, but regretfully I forgot to bring this up in the dojo retrospective. Now I’ll explain why I like the red bar in TDD.

By cheering for the successful red bar, I wanted to underline that making the test fail the right way is clarifying a requirement in an executable form. As I dig deeper into TDD and waddle amidst comments like “I want the tests to drive the design of my application” or “I want my tests to tell stories about my code”, and lately also the new Behaviour-Driven Development (BDD) ideas, I’m staggering towards the comprehension that when doing TDD, we’re not supposed to write tests but to specify requirements.

I’m not sure if Behaviour-Driven Development adds to TDD something more than just the change of the mindset and the vocabulary, but my dojo experience got me thinking that this might be more important than what I had understood. Consider the following (Ruby poker hand evaluator test with Test::Unit):

  def test_four_of_a_kind
    hand = Hand.new ["As", "Ah", "Ad", "Ac", "5s"]
    assert_equal('four of a kind', hand.evaluate)
    hand = Hand.new ["As", "Ah", "Ad", "4c", "5s"]
    assert_not_equal('four of a kind', hand.evaluate)
  end

as opposed to (more or less the same with rSpec):

  def four_of_a_kind
    hand = Hand.new ["As", "Ah", "Ad", "Ac", "5s"]
    hand.should.evaluate_to 'four of a kind'
    hand = Hand.new ["As", "Ah", "Ad", "4c", "5s"]
    hand.should.not.evaluate_to 'four of a kind'
  end

For the record, for this rSpec version to work, I had to add this method to the Hand class:

  def evaluate_to?(hand)
      return evaluate == hand
  end

While Ruby and BDD might or might not be cool, the real point I want to make is that even without the BDD twist, TDD is about design. So what we should practice in a TDD dojo is how to design by writing executable specifications. I think that this is a fascinating, useful and non-trivial skill that is best being rehearsed when working on small and simple examples, such as the tennis scoring and poker hand evaluator which have been the assignments in the Helsinki dojo sessions so far.

Now we have been talking about getting more real-life kind of problems to the coding dojos, so that the participants could learn how to do TDD or at least programmer testing better in an everyday work environment with application servers, databases, networks and whatnot nuisances. Certainly such a hands-on session would accompany well the excellent books on the subject, and help people in adoption of developer testing, but I think that they would be more about the hands-on dependency-breaking or specific technology skills than design.

So although I welcome the idea of exercising in a more realistic setting, I hope that the randoris for doing simple katas will continue as well.

Speaking of dojos, you can now register for the next Helsinki area dojo on Wednesday March 15, 2006 at 18:00-21:00 in Espoo at the premises of Fifth Element. Let’s see if it will turn out more hands-on or micro-level design, but judging from the past experience, at least good time is guaranteed.