Today I finally got my feet wet with something I’ve been meaning to try on for size ever since reading Clean Code, during my trip to Vienna last autumn; wow has it really been that long already, where’d winter and spring hide?

Anyway, so at about midnight last night I finally embarked on the process of coding up a new feature for Twitulater, or at least its server-side bits, after some prep work. Now since this is a rather mission critical system that I’d very much like to be somewhat reliable and rock-solid, unit testing seemed to be the way to go.

Downloading PHPUnit gave me some headaches, because ubuntu’s package managers fucked something up. Why is it I can’t install Pear if there are broken packages for something completely different? Then came the figuring out of how to actually do unit testing and I must say, it was incredibly simple. Of course I did have eight months’ time for the principles grokked from Clean Code to seep in, but still.

Mostly I was suprised to finally confirm that I have been doing test driven development (TDD for you acronym junkies) for a long while. Just in reverse. Whereas now, with automated unit tests, I first write a test, then the code, I used to write the code then test the hell out of it. With PHPUnit testing has become much less of a hassle – run a command, make sure everything works. Nice!

However, unit testing has one large drawback. It took me a solid six hours of coding to produce … nothing. I have in my possession now 200 lines of real code that doesn’t implement much other than making sure users exist and authenticating them, and a bunch of tests taking up a full … 170 lines of code. This is of course after some refactoring and whatnot, the original ratio was always that there were twice as many tests as there was actual code. Yummie.

Now I’m sure many of you will bash me for being such a dirty little blasphemer, but fuck it. Despite all the headaches saved with testing, despite making testing a lot simpler and quicker. It still took me SIX BLOODY HOURS to create some functionality that never used to take more than two hours to code and debug.  This is quite horrible.

And to top it all off, I can’t even be certain there are no bugs in my code! I’ve reached the exact same level of debugged code as I normally would, except that now I can automatically test for everything I could think of going wrong, whereas before I had to invest a bit of elbow grease.

Then again, I probably won’t be abandoning unit testing for mission-critical things any time soon. There is a sense of gratification seeing the tests pass, there is also a sense of “oh my god that was easier than eating a pie” when you run 20 tests and it takes ten seconds instead of ten minutes.

Perhaps most importantly, however, is that with automated unit tests you never forget to run a test. So I guess, in the end, it’s worth it spending those extra long hours to have code you can prove works like you think it should any time. Without spending a bunch of effort on making sure it does.

Unit testing is here to stay, even if it’s a bit of a pain in the arse.

Tags: food for thought, Programming, testing, Twitulater