Unit Testing for the Disinclined

Posted on Apr 12th, 2011 In oops, writing

I work with many engineers used to developing software with a traditional waterfall-ish methodology. Mostly it’s a good experience, but it does mean that I spend a lot of my time talking, demonstrating, pleading, begging, threatening, jumping up and down and holding my breath, all in an effort to get folks to write unit tests. Mostly the argument against writing tests is that it is a lot of extra work that is really pretty optional. “I’ll write the tests at the end,” they sometimes say to shut me up, “If I have time.” After all, we spend all day everyday looking at the code, tweaking it, debugging it and running it. Surely that should be enough.</p>

Which brings me to page 328. Of Eloquent Ruby of course. Page 328 is like just about every other page of my latest book, full of breathless prose and numerous coding examples. Writing code for a book is a lot like writing production code, but with a few special twists. It’s like writing production code in that the book code has to work: Hell hath no fury like a reader who has just tried to run an example and found that you missed a comma. Book code is different from regular code in that it doesn’t go into production, it goes onto the page. For Eloquent Ruby, I attacked the twin problems of making sure the code worked and making sure it landed on the page by writing a couple of Ruby scripts. One script runs all of the RSpecs associated with the code to verify that it does indeed work. The other script extracts all of the interesting bits of code (bits that are marked off by special comments) and inserts them into the right places in the manuscript.

Except that I didn’t do that everywhere. There were a few places where the sheer difficulty of writing a working program or simple laziness drove me to write the code directly into the book without the benefits of a spec. There were only a handful of these and during the review phase of writing I made a point of taking a careful look at each one: Gotta check those untested code samples, just to make sure they work. Which brings me back to page 328. Right there in the middle of the page is one of the handful of code examples that I didn’t run through RSpec:

class Automobile > ActiveRecord::Base
  has_one :manufacturer

Do you see it?

That > should be a <. Putting that > in a class definition is one of my very favorite Ruby syntax mistakes to make. For what it’s worth, my subconscious is convinced that since there is likely to be more stuff in the subclass than in the superclass, it only makes sense that subclass > superclass.

Whatever the dark psychological forces behind it, the fact is that I got that code example wrong. Looking at this statistically, the broken example above is one of  five in the book that is spec-less. That’s a 20% error rate. Now I don’t know what the real error rate is in the other 600-odd examples in the book – after all the book hasn’t been out all that long and there probably are some lurking bugs. But if there was anywhere near 120 coding mistakes in the book (20% of 600) I think I would have heard about it by now. My guess is that that the error rate for the Spec’ed examples is at least an order of magnitude less than for the untested code.

Now step back and think about this with me. I got the Automobile example wrong even though it contained a glaring mistake. I got it wrong even though the mistake was one that I know I make. I got it wrong  even though I took some extra time to eye-ball it to make sure it was right. I got it wrong while I got most, if not all, of the other 600 examples, the ones with RSpecs, right.  If that doesn’t convince you of the utility of unit testing, well, I’m just going to hold my breath till I turn blue.

The Darned Title

Posted on Mar 11th, 2011 In writing

The last two words written for Eloquent Ruby were the ones that went into the title. The funny thing is that the idea behind the book never wavered: Write a book that would explain how Ruby is really used, with an emphasis on topics that ‘we all know’.

So the theme of the book was easy, what was hard was coming up with a title. Initially it was going to be Effective Ruby, a homage to one of the most influential Java books ever. Unfortunately, there is a fine line between homage and copyright infringement and the AW lawyers were, well, nervous.

So, then we turned to Elegant Ruby. I never liked that title much, but it was what we wrote on the contract just to get the ball rolling. For a while I tried to convince myself that Fluent In Ruby or maybe Fluent Ruby would work, but the fact is that I hated both.

Then I thought I found the solution: Elements of Ruby Style. “You’re kidding, right?” said the lawyers. By this time we were in the midst of copy editing, the small matter of actually writing a 400 page book a quick stroll in the library compared to the serious task of picking a title.

Fine I said, Elegant Ruby it is. The final touches were going into the MS when I heard that no, because of some other stuff that was going on, Elegant wouldn’t work either. At this point my wife Karen, a calm and wise woman, said these calm and wise words: “We do own a thesaurus, you know.”

And so we did, and right there near Elegant was Eloquent. And Eloquent Ruby it was. Then a few days after the book was officially published, I heard from Marijn Haverbeke, author of Eloquent Javascript. Sigh. I had no idea there was another eloquent programming book out there.

But it all works out. While the saga of the title seemed to stretch on for half my life, the folks at AW have had to put up with a lot more from me than vise versa. And Marijn turned out to be one of those wonderful people that you meet in the twists and turns of life. So it’s all good.


Good Code And Good Jokes

Posted on Mar 7th, 2011 In oops

On page 8 of the book, after warning against commenting too zealously, I said:

Remember, good code is like a good joke: It needs no explanation.

Except that I didn’t actually say that, at least not originally. That line is a bit of old school programming wisdom that I’ve heard many times over the years. I thought I was repeating a fairly obvious old chestnut. I certainly should have said so in the book. So, if you are the wise old coder who said this originally, my apologies.


Are You a Rule Breaker?

Posted on Mar 1st, 2011 In rules

Eloquent Ruby ends with a plea not to take all of the rules too seriously. I’ve always thought that the best best practice is to think for yourself.

So when should we break the Ruby rules? Leave a comment and let me know what you think.


All articles…