My Apprenticeship - Thursday, August 5, 2004

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.

Thursday 8-5-04

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.

Comments

Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a teacher I took a b
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is
Read more