TDD

In preparation for CAMDUG's first ever Dojo yesterday, I worked through the Leap Year kata, which I had intended to run in the first session, "Introduction to TDD". I ended up swapping it out for the Roman Numerals kata, because I got through two iterations of the exercise in about 20 minutes. However, I thought it would be useful to share the problem and my approaches to it with my readers.

Yesterday, CAMDUG, the Cambridge Developer's Group, ran its first coding dojo generously hosted by my employer Granta Design (we're hiring!). Rooted in the principles of Software Craftsmanship, dojos bring developers together to sharpen their Test-Driven Development and Design (TDD) saws.

Today I spent most of the day pairing on a task with another developer. This is unusual for our company (the usual arguments fears are raised) but we both found it a useful experience. Here's what I learned today.

As part of the pairing scenario, I suggested using a ping-pong test-first approach:

I've recently started reading Kent Beck's excellent book Test-Driven Development by Example at work as part of my self-development goals for this quarter. Test-Driven Development (TDD) is something that I'd heard about, and knew the basic principle of (write the unit tests first and write the code to pass them), but had never tried or bothered to read up on.