How Will I Know When it Works?

If you are writing code I would assume that you're always writing it for a purpose. Sometimes the purpose is only to experiment or learn but you always have a purpose. You are creating something, solving a problem, or doing something fun. More importantly, your code should have a purpose and a reason to need to be written in the first place.

The first thing you [should] ask is "How will I know that I have solved the problem?" If you don't, how do you know when you're done? Also, what if The Problem was solved but you (or someone else!) just made a change elsewhere in your code base and now your code broke. How would you know? More importantly, WHEN will you know? Will you find the bug before your code goes out the door, or will you have a customer complaint about a bug that should have been discovered months ago?

How Did I Ever?

At this point I have to wonder to myself, how did I ever develop functional software before? It was great to start writing tests that failed, knowing they failed and then fixing the problem. At the core it works well with my personality for two reasons. First, I like being able to mark things as complete. I like the feeling of accomplishment of marking tasks off the list. And what better to-do list could I have then a set of failing tests. They're visible. I know they're broken and they keep coming up as failing tests... until I fix them.

The second reason it works well for my personality because I love the problem solving process. I noticed that when I wrote a failing test and was able to easily fix it in the next commit, it was a great feeling of accomplishment every time. Even for the silly little tests.

This was my first TDD-type experience and I still believe that I'll never be a TDD religious fanatic because while it feels right sometimes, other times it isn't appropriate. Once I trained myself that I can trust the unit tests (It took a while before I stopped double checking my tests after every build!) I found myself slipping into wonderful states of zen while writing code. That isn't a state of mind you can force, it has to happen naturally, but once I got in my zen state I stopped writing tests first and instead wrote a few methods lickity-split! That lasted for a little while, but once it started fading I immediately started writing the tests to cover my new code.

Right tool for the right job... Sometimes TDD works, sometimes it doesn't. That's why I try to avoid becoming a zealot for a particular methodology, such as TDD, XP, Agile, PMI, etc. I believe that each has its merits, each has its weaknesses, and being familiar with more tools gives you more flexibility to choose the correct tool.

Benefit of Unit Testing

Last weekend I completely refactored one of my projects to have a much better cohesion, directory structure, and reduce some of the redundancy that has been introduced (by me of course). It ended up being a much bigger project than I anticipated, but I was able to complete the transition almost seamlessly because of the unit testing I had put in place. Without the safety net of my existing unit tests, I would have continued pushing back this project which would have only further complicated it with accumulating technical debt.

Just Do It (Unit Testing)

Please, for your sake. Start unit testing. Start somewhere tiny, small, and easy to dig into. It took me much longer than it should have to embrace unit testing and I have nothing but excuses for why, no real reasons. I can only imagine how much better my code would be today if only I had started the change a year ago instead of two weeks ago.