title: Test Driven Error Resolution date: 2011-10-17 comments: false post: true
If you’ve been developing with Ruby on Rails for any length of time, you are no doubt familiar with Test Driven Development (TDD). You can use TDD in other languages - and I would encourage you to do so - but no other community I’m familiar with puts nearly as much emphasis on testing as the Ruby community. If you are unfamiliar with the concept, I invite you to check out the references in the ”Further Reading” section below.
Assuming you are familiar, then you know the drill:
That’s a general summary of TDD and it’s where most articles end, but that leaves one crucial step out.
The part left out is what happens after you have deployed your product. TDD is a great methodology and it aids us in thinking through the problems we are trying to solve as well as reducing the number of errors in our product, but as they say, there are no silver bullets. We make mistakes, we misunderstand the client’s needs, we don’t account for how the user will use our application, and sometimes we just miss something. When that happens, errors arise.
When the inevitable error occurs you just tweak the “write a failing test” portion (Step 1) of the TDD cycle. Something is already failing, so you write your test to duplicate that failure. If you receive a notification that logins fail when users have “dash” character in their email address, then write a test which attempts to login in with an email containing a “dash” character.
After that, it’s TDD as normal. And so our new process looks like this:
This is no great revelation, but oftentimes in our hurry to solve the immediate problem we forget, or lay aside, best practices. Don’t fall into that trap. Squash the bug, but do it with tests.
I live in the greater Kansas City area with my beautiful wife, our two great kids, and our dog. I've been programming using Open Source technologies since '97 and I'm currently an independent software developer specializing in Ruby on Rails and iOS. I am for hire.