This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.
Well, knowing more about mocking objects would have helped a lot when I was writing my TDD Tic Tac Toe. Mocking Objects was, of course, one of the subjects of today's class. The whole day was devoted to TDD (the first day we were refactoring existing sample code) but I was pretty familiar with most of it except for the mock object pattern. Which seems like a big part and just goes to show that sometimes it's nice to have someone explain something to you even though you think you already understand it.
I'm working with a possible future intern: Matt. He's at DePaul and might be helping OM out in the fall (he has to work around his class schedule). Matt's been taking a bunch of non-computer classes this summer so he's a little rusty in the programming department. And he keeps wanting to write code without tests. However, I remember my first day at OM when I couldn't even get a simple bowling score program to work (yes, they try that one out on everyone). It's hard pairing with somebody who knows a lot more than you. Can be intimidating.
Five years down the line I'm still learning something about testing every day. I'm giving a talk entitled "What's the Right Level of Testing?" at Agile 2009 and Lone Star Ruby Conf -- in it I discuss the difficulties of balancing testing, team moral, velocity, assurance, and code quality. After looking over my slides I have to say that most of the teams I've been on have gotten it wrong more often than right. Which is all the more interesting because I've been working at the test-friendly ThoughtWorks and Obtiva. Testing is hard (but seems deceptively simple) and it can easily be over or under done.