Test Driven Development
Back to my roots
A couple of weeks I was given the opportunity to take some time-out to go back to my development roots and take part in a coding course. As it turned out, that course has genuinely made a difference to the way I think.
Prior to fully entering the world of user experience, I spent many-a-year developing in various languages; assembler, C++, C#, objective-c and HTML/CSS/jscript (as well as a few others). However in all that time unit tests were more of a chore than a goal.
I have had some exposure to Test Driven Development (TDD) through some lunchtime sessions run by a couple of colleagues at work; I like to go along to ‘keep my hand in’ and also to work along side folks from other departments. However, due to the brevity of those sessions I didn’t appreciate the full extent of the switch over needed.
And so it begins
As the course started, I was a little taken aback by Jason Gorman, the course tutor, stating that “anyone who isn’t going to give it a chance should leave right away”… a slightly surprising way to begin the day so I’m guessing that he has seen some resistance to the technique in the past, a good way to weed out anyone who does not want to be trained, though. For my part, I liked the way that right from the start we were pairing up to code and getting stuck in.
The way that the technique turned development into a mini-goal oriented process made it extremely easy to get going. I’m used to designing on paper up-front before translating into code so that jarred slightly – even with the simple exercises we were doing, but the mechanism certainly lent itself to chunking up the problem into manageable nibble-sized pieces.
One things are set up – with you project and its accompanying unit test module – read the brief and get going. The key to tho whole thing seems to be sticking to the steps of the highly iterative process; those being:
Write a failing test.
Fix it in the simplest way.
Refactor the code.
There are also a collection of best-practices to adhere to along the way such as making sure each test can only fail for one reason and restrict your use of copy-paste (to reduce the chance of duplicating errors). I did find copy-paste a very tricky habit to break.
As for the pairing; this technique again really works well here with one developer writing the test, another fixing it and then hand back for a refactor – or whatever suits best.
Not really shaken, but definitely stirred
As you might have gathered; I came out impressed. I like the goal statement followed by the breaking down of that goals into tiny goals that allowed you to meander your way towards a [fully tested] solution. I liked the continuous sense of progress as each mini-goal was completed.
I also enjoyed identifying those goals through user stories – albeit with slightly different verbage to those from the UX world. This seemed to me like a great way to proceed.
Subsequently, I have begun to do the occasional coding kata in objective-c using TDD and I don’t think I have ever found getting unit tests to pass quite so rewarding. If you have the chance, TDD is definitely worth a look (and this was a great course).
Right, back to user experience land