Last tuesday I was fortunate enough to get along to the first Preston Codejo, organised by Gemma Cameron and Jeremy Coates and hosted by Magma Digital. We’ve recently started doing Test Driven Development (TDD) at work using PHPUnit, but it’s a case of the blind leading the blind so I was looking forward to hearing about it from people who do it day in, day out.
The kata that we ended up working with was based on Bruce Forsyth’s Play Your Cards Right. Given two input cards, the script had to return the card with the higher value (or a standard message if the cards were of equal value). We solved it in Ruby (you can see my attempt on Github), but no prior knowledge of Ruby for TDD was required.
If you’re interested in the process we followed, there’s a good writeup over on code and effect.
Personally, I found the evening both very useful and very frustrating. It was reassuring to see that the tests that were being suggested and written matched up to the kind of thing we’ve been writing at work. I also enjoyed trying out Ruby, which is very easy to get to grips with. TDD in Ruby seems much more common (and much easier to get the basics working) than it is in PHP. If I wasn’t starting to get into Node.js more, then I’d definitely be taking a look at Ruby.
As for the frustrating aspects, they were mainly down to personal preference and all came up in the retrospective, some of which were mentioned by others, some by myself.
I found it very difficult personally to work with the Randori format that was being used. It demands complete attention of the entire audience on the two people currently working on the problem. When the dojo lasts for 2 hours, and you only have 5 minutes on the keyboard it’s very difficult to stay focused. A few times, the audience got caught up in their own discussions (usually revolving around Ruby syntax) and Gem had to pull us back into the dojo.
Another thing that I struggled with, was that we were doing something close to TDD “as you mean it”. When it was my turn on the keyboard, I had the job of turning the 4 picture cards into numbers. I instantly copied a test and starting writing four tests in a batch, one for each. I was quickly pulled up on it and told that in TDD, you write one test then make it pass before moving on to the next. I didn’t see the point in this, so long as you solve the tests one by one. I also didn’t agree when Tim started to comment what he was doing, but was told that we don’t need comments as the tests would describe the method’s purpose.
Both of these issues came up in the retrospective, and we managed to agree that in the real world, yes, you can write multiple tests at once if they’re similar. We were being very strict as there were people with no exposure to TDD at all attending, and one test at a time is the easiest way to introduce them to it. As for writing comments as well as tests, there’s nothing to stop you doing it. Personally, I’d rather have comments as it means I don’t have to keep two files open, just the one I’m working with.
Finally, the retrospective touched upon what the codejo is, and what it’s planning to be in the future. Whilst we’re working with Ruby and TDD at the minute, we might swap to C# in a few months and do TDD with that for a while. After that, we might take a look at system architecture. The codejo is about professional development overall, not a specific language or process.
Overall, it was a very useful event. The next one is pencilled in for January 2012, and will be split into two sections. The first half will be a Randori (using Ruby again), and the second half will allow people to pair off and try and solve the kata using whatever language and methodology they want to use. I’m looking forward to seeing what people come up with as I’m sure that different people will have different solutions to the same problem.
I’ll definitely be there in January, and if you’re based in the North West, you should be too.
Michael is a polyglot software engineer, committed to reducing complexity in systems and making them more predictable. Working with a variety of languages and tools, he shares his technical expertise to audiences all around the world at user groups and conferences. You can follow @mheap on Twitter