One of the biggest complaints I’ve heard about Test Driven Development is that developers don’t feel like they have the time to create the additional code in the tests. I completely understand the feeling. Lets face it, as developers we hardly ever hear from our customers “Take all the time you need.” It always seems like we either need to have the wanted functionality finished yesterday, or we have so many projects going at once that work feels more like a juggling act; doing just enough on each one to keep the wolves at bay.
But I would argue that this time crunch is exactly the reason we need to be writing tests, and letting these tests drive our solutions. A recent example demonstrates how testing creates simpler, better defined code you can feel better about.
A month, or so, back I was tasked with adding a new member class to a new Ruby on Rails application I am working on. This required adding fields to forms, adding entries to some underlying tables, and substantial changes to the object we had backing the forms. All pretty routine stuff. Because I am fairly new to Rails, and I wasn’t completely sure on what behavior I wanted the application to have, I just started writing the application code; figuring I would go back and cover with testing once finished. Adding the needed fields and database entries was pretty straight forward, taking very little time. I then spent the better part of the day putting the needed functionality into the form-backing object (namely adding and updating the new member class).
I started by copying similar behavior already in place for a different type of user in the system. Seems like a logical step, right? Should be pretty safe and straight forward. It wasn’t long before I started getting very uneasy about the code I was writing. There were more than a few conditionals, fragments of code in multiple places, and, most importantly, I wasn’t sure it was even doing the thing I needed to have done! This is a very scary way to feel. I quickly realized this was not going to work and backed out every change I had made to this object, choosing instead to start fresh the next day with some fresh eyes and a partner to do some pair-programming with.
The next morning we started out fresh, being sure not to write a line of application code without first having a test to cover what was being done. In true paired-programming/TDD fashion we alternated writing test and application code. By the time we were done, we had written fewer lines of application code than I had previously, had a nice little suite of tests, and, most importantly, we were confident the application now did the thing we needed it to do! So not only did we achieve better code through testing, but we did it in less time than I had spent by myself doing it the wrong way.
So remember: you may not have a lot of time to get the work done, but you always have a choice in how you do the work. And in the long run, better written code backed by tests will help you sleep better at night.
Our troubles came in the fact that the interface provided by the fog-aws gem does not currently have any way to tell it to assume a different role. It does provide a way to use a role your server may already have been assigned, and a nice mechanism to re-negotiate your credentials when they are about to expire. So what do we do when something doesn’t quite work the way we want? Monkey patch!
