Unit testing is anti-productive

Jun 23 2009 Tags: , , ,

Blogging burns a lot of caffeine. If you enjoy my posts, you should buy me a cup of tea.

Buy tea
Salish Mist
Image by ecstaticist via Flickr

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.

---
Need a freelance developer? Email me!

You should follow me on twitter
 Subscribe to RSS

8 responses so far

  • Terry

    Your title is a bit extreme considering that the time savings for having automated unit tests add up substantially over time for long term code compared to having to manually test your code.
    Unit testing is actually *very* productive when you look beyond the one time cost of writing a test before you write your code and after that the investment pays off in spades compared to having to repeat manual tests or reason about the code whenever you make a change to a complex or mission critical system.
    Unit test aren’t recommended for quick throw away scripts that you believe won’t be reused though. Funny thing is a lot of code does end up getting reused again somehow so it’s not an easy call either.

  • Ben

    Thing thing you are missing is when it comes to maintaining code. When something does break and you come along and fix it your unit tests make dammed sure that you fix it properly. You also then create another unit test to capture that issue.

    Now im not a fanatical unit tester. I do write them but really only use them for ensuring things will still work later on. That said however they have saved myself from releasing broken code many times.

  • http://hammingweight.com Carl

    Writing tests take time and they slow you down. But this can be a good thing: while writing tests you’re forced to think not just to code. The author of “Code Complete” observes that he wouldn’t trust a coder who never just sits thinking rather than coding.

  • swizec

    Yeah I guess you all make a good point. Unit tests aren’t for when you’re coding, they’re for two years later when you’re having problems.

    Dunno, maybe I have to get used to them still, but right now they serve mostly to pull me out of the flow and keep jarring me to think about things I don’t feel like thinking about right then. I’m trying to solve a problem, being forced to also solve the problem of testing the solution is just … overkill.

  • Pawel D

    Plus it is especially important in languages with dynamic typing. As you never know whether you have just destroyed one of the “old” functionalities implementing “new” one. For simple project though, I would not bother with all that TDD (its not that I would not bother with unit testing at all!); for really complex ones, developed by tens of devs – its a must (at least from my experience).
    Additionally it took you considerable amount of time but you should be quicker with writting unit tests as you gain experience (YES – writting good unit tests in short time is a skill!).

  • Jeff

    Your solo coding doesn’t scale.

  • http://pantras.free.fr Philippe

    Perhaps you just experienced a steep learning curve.

    You wrote you were used to practice “reverse TDD”, but how do you test then ? manually ?
    Then it is test-driven, however, it cannot be called TDD.

    Do you think you would have achieved more by writing the test last ?

  • Pingback: Cthulhu and other crazies » Blog Archive » The ten pros and cons of unit testing

« Slovenia desperately needs more... Our digital lives are empty and sad »