I’m definitely one of those programmers that believes that a programmer’s true calling is to create bugs. After all, if we don’t create them, we’ll have nothing to fix and fixing a lot of issues looks really good when performance reviews come around. However, writing bugs comes with the added hassles of irate customers and frustrated qa people. These two are normally don’t look so good when performance reviews come around. But… committing buggy code saves you from the annoyance of making a change, compiling, restarting jboss, clicking through a bunch of screens just to discover that you wrote ‘LIKE’ instead of ‘ILIKE’ in your query, and then repeating ad infinium. On one hand, you have irate customers on the other you have mind-numbing clicking. Either way, you’re likely to lose your mind.
The slow decline towards insanity lead me to experiment with unit testing. Only a crazy person would dare to figure out why 99% of the written unit tests failed. Eventually, they started to work, and it became clear that it might not have been so crazy after all. Although it sounds ridiculous, the test-driven proponents claims that unit-testing saves developer cycles really is true.
That statement is very counter-intuitive. How on earth can writing twice the code save me time in implementing a feature? It really doesn’t make sense, until you realize that by the time you’ve waited for ant to finish, jboss to start, and you’ve had the time to click through the 5 screens, it’s been half the time it takes to write a test case. By the second run, you’re even. With a decent IDE, you don’t even have to wait for a compile. Also, since test cases run in a minimal context, they take a fraction of the startup time as JBoss. You pay Somewhat high initial cost, but almost no recurring cost.
Of course, if you’re using a homebrew stack and framework, there might be astronomically high initial environment setup costs that negate any benefit you could achieve. Thankfully, all the major frameworks make it dead simple to write useful test cases. Spring gives you an autowire test context that you can extend. In this context, all your beans will magically just work. Rails goes even further by providing tools to create data and migrate your database on top of just running tests.
It took a while, but I’m firmly a believer now. I hate clicking through screens, and this gives me a programmer-friendly, automated way of making sure my code doesn’t suck and actually works. Once you get used to it, there’s little not to like.
