Scrabbling up the Learning Curve

A few months ago I was at the peak of my powers.

I was leading a team of ten C# developers building a huge project on Microsoft’s .NET platform. I had been working on the Windows platform for years, and there was rarely a question from the team I couldn’t answer quickly and confidently, drawing on a deep well of past experience.

When doing TDD it goes without saying that you write the spec or test before you write the implementation. When that implementation will involve an interaction with some dependency, you’ll need, as part of your spec, to precisely describe the way that interaction will happen in terms of mock object expectations, or some other sensing on a fake of the dependency.

In order to do this quickly and easily, you’ll need to

• Understand the API for the dependency (or at least the subset you’ll use)
• Know how to express the interaction with your dependency in a mocking framework.

As I start to learn ruby and the rails framework, I’m quickly realising how much harder it is to do TDD when you don’t have a clue what you’re doing! Or more precisely, you don’t know the system APIs well enough to confidently say how you’ll want to call them to get the behaviour you want, without a little prior experimentation. And even when you do, you may not know your local neighbourhood mocking framework well enough yet to ask him to do some more involved stuff, like validating arguments sent to mocked out methods.

When you hit that ‘how do I…’ barrier, it’s tempting, often even necessary, to break out of the TDD rhythm and do some ‘scratch coding’ as Michael Feathers would call it.

Just make sure you roll-back your working files before you write that first test, cowboy!