Coding is like gardening...

Archive for November, 2008

Personal victories

I love it when you can refactor a bulky, ugly function down into one line. It always makes me very happy indeed. Here is my solution for outputting a person’s name in a nice format, taking title, initials, first name, surname, suffix. Initials take precedence over first name.

This is how i did it originally:

  def contact_display_name
    returning String.new do |output|
      output < < title + ' ' unless title.blank?
      if initials
        output << initials + ' ' unless initials.blank?
      else
        output << first_name + ' ' unless first_name.blank?
      end
      output << surname + ' ' unless surname.blank?
      output << suffix unless suffix.blank?
      output.strip!
    end
  end

Rather too long-winded for my liking. I managed to refactor it down to this:

def contact_display_name
    [title, (initials? ? initials : first_name),
      surname, suffix].delete_if(&:blank?).join(' ')
  end

Of course, it is another advantage of behaviour-driven development, that i had already specced out what i wanted to happen, and i could use the specs to ensure that my two versions of the function were equivalent. See below for the specs that verify the behaviour.

(more…)

Posted on: Friday, November 21st, 2008 Posted in bdd, code, refactoring | 2 Comments »

Cucumber is a joy

Cucumber, the replacement for the rspec story runner, is an absolute joy to use. It only takes maybe a few minutes to move an old set of stories over to Cucumber features, plus you get full language support, something one of our coders might have taken slightly too far :-)

We’ve now switched all our active projects over. I highly recommend you do the same if you haven’t already – it’s a real step closer for us to the ideal situation where customers can collaborate on the text their own stories. Aslak and the rest of the team have a lot to be proud of.

Posted on: Friday, November 14th, 2008 Posted in bdd, code, rspec | Comments Off

The proof is in the testing

I am a recent convert to behaviour-driven-development (BDD) and this idea of writing stories and specs before writing code. Before I joined Eden Development, testing was always something that sounded like such a good idea … but I just didn’t have the time! Now I can’t imagine writing any code without tests. The idea seems positively frightening!

Here are some reasons why i have been won over by the test-first philosophy:

1. One thing at a time
Of course we all like to write very small concise functions, don’t we? But even in a small function, there are usually a few different paths that could be taken through it. It is so beneficial for me to think of scenarios one by one, write up the expected outcome, and then write the function a little bit at a time until it passes all the tests.

2. Confidence
Let’s be honest – who wants to go back and manually test all the things that you’ve tested a hundred times before and you’re pretty sure they’re still going to work? I used to be a tester – that was my job – and I couldn’t stand the monotony. But you can never have complete confidence in your whole system unless you have tested all of it. If you have broken something, it’s much better to know sooner rather than later. When you have a complete set of tests to run after every test you can be completely confident in your application.

3. Prove the obvious
Sometimes I’m writing a piece of functionality and I think, “Oh that’s so obvious – I don’t need to write a test for that!” But then I think to myself, if it’s so obvious then I had better make sure that it stays that way. In any case, it may not be obvious to the next person who works on this bit of code. It may not even be obvious to me in a few months time. So I write a test to prove the obvious. If somebody changes it and breaks the test, then they will be forced to think twice about the change they are making.

4. A greater understanding
Step-by-step stories are a wonderful way of understanding a system. Often when I’m coming to a piece of code I’ve not worked on before the first thing I do is work through the story. It may be enough just to read it through to see what happens when, and why. Sometimes I literally follow every step of the story, performing it manually to see for myself what it does. Once I understand what is supposed to happen, I’ll have a far better chance of following the source code. So be kind and write nice stories for the next person who comes along and wants to understand your code.

We write our behaviour-driven-development stories and specs using RSpec, and we are currently converting to Cucumber to run our test suites.

Posted on: Wednesday, November 12th, 2008 Posted in bdd, testing | Comments Off