Unit Testing

I love testing, I could hardly wait for this meeting of the Chicago Ruby Group. I was not disappointed. Unit tests are cool, but specs are awesome. Whats the difference you say? I think its a more natural way to write your tests, it makes you think of the behaviour of your object and not "oh gosh, I have to write 3 tests for each of my methods."

Somedays as a developer you really know that your work affects the bottom line, and other days you are putting lipstick on a pig. This is my story of how I once saved my company a whole penny through a day of in the trenches code sleuthing. Money machine or hog hairdresser? You decide.

Since I've been talking about Unit Testing quite a bit recently, I thought I'd offer up a review on a book I read a while back. I thought it was a solid roundup of both the principles and the tools used to support Extreme Programming in Java. Overall, I'd give it a 9/10 and I deduct a point solely due to the fact that since it details the usage of numerous Open Source projects, it's halflife could be very short. Regardless, this is more than enough to get you started and will teach you the basics to be able to do even more interesting things.

Just to make this clear right off the bat, if you're not working in Java, only pages 11-27 are going to be of any use. These pages go over the different pillars that make up Extreme Programming (XP). Whether you're using XP or not, you can pick and choose the pillars you need and customize them to your project pretty easily. The principles are: Pair Coding, Unit Testing, Refactoring, Iterative/Minimal Upfront Design, and Regular Builds. I have yet to see a project that cannot benefit from having Unit Testing and Regular Builds in place. These two items serve as a great safety net for current and future development efforts by detecting errors soon after insertion.

No real substantive post today; what started as a busy week has turned into a nightmare, complete with some very bad news about a very old friend.

Well, life goes on, and with it, work. On that front, my company is in the process of our first ever project post-mortem. One of the questions that's come up is the amount of hours spent unit testing vs. improvements to code quality. We had to fight to get hours in the schedule for UTs, and we got them. But now we're faced with the "Prophet's Dilemma": we predicted quality would suffer without unit tests, and we got unit tests, and now we can't prove that code quality would have suffered without them.

Alright, so I admit that I'm completely biased. I can't be impartial about it and I don't think you should be either. Once you begin writing Unit Tests - or better yet Test Driven Development - you don't want to go back. Once you have a series of Unit Tests for a particular class, method, etc, it's painful and scary to modify code lacking these tests...

I'm a big advocate of Agile Methods and principles. I believe quite simply that an evolutionary design, refactoring, user stories, and especially Unit Testing. So when I came across the concept of Enemy Unit Tests, I was dumbstruck by the logic of it.

Think about it. When we right code, we write Unit Tests (hopefully!) and run them as often as necessary. You may not run all of them all the time, but you run the important ones as often as possible.

Now what about all those libraries you're using? When was the last time you tested those?