writing a test for a bug before fixing it: a good idea most of the time

I’m not fully onboard with test-driven development, but I have started to like it a lot when I’m fixing bugs. First I reproduce the bug manually in the product, then I write a test for it that fails, then I fix it and makes sure that the test passes. Good stuff!

Friday I started working on a bug that I was surprised to see, because I had written a test that I thought should cover it. So I tried it manually in the product, and was easily able to reproduce it. I noticed some differences with the way the test was set up, so I started trying to tweak the test to get it to fail.

And I spent like 4 hours trying to do this, getting more and more frustrated. I could not for the life of me figure out what was going on!

Finally I said “whatever” and investigated the bug in the product. It took me like 10 minutes to find the cause of the bug, which also revealed why my test hadn’t caught it. Another 20 minutes later, and I was able to make a test that failed without the bug fix and passed with it.

So this is a reminder to myself: it’s OK to do things out of order sometimes!

Leave a Reply

Fill in your details below or click an icon to log in:

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