Test First

I got a great lesson in test first today.  I had fixed a bug earlier in the week, but I really didn’t get much gratification.  I also had to test it, realize another problem, fix again.  You should see a pattern forming here.

So I called up another team member and asked for some help figuring out how to get a spec (a.k.a a test) to cover this error in the event that there is a change in the future.  It was kindly brought to my attention at this point that I should have written the spec first anyway.  This is part of the whole methodology that we’re following anyway.

I reverted my code and wrote a few specs, passing each as I went along.  Sure enough, there was the gratification I was longing for.  Now the code is a bit more hardened.  I could have easily written the specs after the code fix, but there are two problems:

  1. The specs may not have enough coverage, it’s just too easy to be lazy in this direction
  2. You understand the solution to the bug better because you are describing how the application should behave

Here’s my light analogy: Your lightbulb burns out, finding a bug and fixing it is like just replacing the 60W bulb with the other one that came in the 2-pack you bought.  Writing a spec first, then fixing the bug is like putting in a 75W equivalent CF bulb to replace that incandescent.  Hoo ahh!  Yeah, it’ll cost more, but you’ll save money over the long term and burn a heck of lot brighter (at least mine do).

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: