Why I hate Test Driven Development

by Rob Galanakis on 30/03/2012

I have no problem saying that I write good code. I place a focus on TDD and thorough unit and integration testing. I document everything I write (not just function documentation- I document classes, modules, and systems). The fact is, since I’ve been doing these two things somewhat religiously, the amount of time I have spent debugging code has gone down dramatically. There are just not many bugs to find in most of the code I write, they are easy to narrow down when I find them, and they rarely regress.

This is a good thing, isn’t it? So why do I hate TDD?

Because debugging is fun. There, I said it. I love debugging. I think lots of clever people like debugging. I love someone having a problem, coming to me, looking at it together, getting up to walk around, look at the ceiling, talk to myself, stand in front of a whiteboard, draw some lines that spark some idea, try it, manually test a fix out, slouch down in my chair staring at my computer lost in thought, and repeating this until I actually find and fix the problem. Not just think I fixed it, but really sure that I fixed it because suddenly it all makes sense. At which point I spring a terrific boner for my obviously superior brain power that was able to find this problem that plagued mere mortals.

So the sad fact is, since I’ve been doing TDD, I haven’t been able to go on this ego-trip a single time in our TDD-written codebase. Sure, sometimes we get a bug in the UI, but those usually manifest easily. Oh, and I’ve definitely used some frameworks and API’s improperly and caused bugs because of that. But those are the annoying types of debugging we all have to do, not the  magical mystery tour described above.

I didn’t realize how much I missed debugging until it was gone. Fortunately, there’s still lots of legacy code and API’s to get my fix from.

rob.galanakis@gmail.com

There are 25 comments in this article:

  1. 30/03/2012Jason Parks says:

    Oh the trials and tribulations of being too good. You poor, poor soul. So much exciting drama you are missing out on.

    (I agree, cannot stop writing unitTests. Anything I write that doesn’t have a corresponding test, leaves me shuddering with its potential to explode.)

  2. 31/03/2012blub says:

    You should debug the collision detection of Eve. I’m sure that implementation has more bugs than code lines.

    By the way, I know what you mean, but I found an alternative: Profiling. Tracing bottlenecks down and removing them is the same fun as fixing bugs.

  3. 31/03/2012Rob Galanakis says:

    Lol, I don’t want to think about EVE collision. Have you ever seen the collision balls on a ship?

    Regarding profiling, that’s a good one!

  4. 1/04/2012Avi says:

    I hate to tell you but now you can even stop debugging legacy code. Sorry for the bad news, but you can even test complicated legacy code with tools like Typemock Isolator (for .NET) and Isolator++ (for C/C++ in Windows and Linux). Check it out at http://j.mp/H79z6s.

    If you’re interested in starting Unit Testing, there’s a webinar on Wednesday that I recommend: http://j.mp/H79HTp

  5. 1/04/2012anon says:

    an ego-tripping .net developer, what’s worse?

  6. 1/04/2012Rob Galanakis says:

    Anon: An ego tripping C++ developer?
    Avi: Unfortunately, and I find your view common from people in the web dev world, us in the game dev world often accumulate so many bad practices it is impossible or impractical to use many 3rd party tools or frameworks. We can’t even run almost any of our python or C++ code that goes into our game engine from outside of our game (and often, outside of our client). This is one reason my team develops almost all of our code to run in regular python interpreters, but our legacy codebases don’t have this. Actually, most of our game code isn’t structured so that a regular python interpreter could import it. So, for example, even if we have unit tests for our game code, we have no way to run them because getting the game hooked up into CI is difficult, so we’d have to build more custom solutions, which only gets us further into the hole. However, thank you for the link, I’ll give it a look.

  7. 2/04/2012Jonathan says:

    You might want to try some recreational rigging. I get that same feeling trying to figure out why a rig is broken in one scene but fine in another, and as far as I know, no one’s developed a way to unit test character rigs.

  8. 9/04/2012Chris Calloway says:

    If you love debugging, you’ll really love TDD. With TDD, you get to debug all your test code.

  9. 28/05/2012Vineet Bhatia says:

    Chris Calloway :
    If you love debugging, you’ll really love TDD. With TDD, you get to debug all your test code.

    Awesome reply!

  10. 28/05/2012david karapetyan says:

    Can’t tell if sincere or just a douche.

  11. 28/05/2012Uday k says:

    Spend your new found time on creating new projects to solve real world problems !

  12. 28/05/2012bro says:

    I’m sure you were waiting for this, but you most live in a bubble. If you’ve actually set down and started to create something “new” or had to “get something done” then you will probably soon realize you can’t write that extra test because “it just works”.

    Here’s the thing. TDD works great in a bubble. Then all of a sudden you either have millions of users and can either take more time to run/test/verify or you can fix the bug – and get back to life a usual with happy users. Or you are a small team and have a growing product – you bootstrapped and you have to decide between a new feature ready for primetime on monday to land a game changing client or write those extra tests… Or you are exploring and hoping to learn a new solution to a problem spiking out features with customer feedback tweaking and adjusting…

    Anyways, some test coverage is a must, test first is a fail IMO… but to each is their own, best of luck to you!

    Bro

  13. 28/05/2012Mick says:

    What is faster? TDD or debugging?

  14. 29/05/2012greg nwosu says:

    @blub +1

  15. 29/05/2012Thorsten Mueller says:

    But there is still the part of programming where you implement new stuff that has not been done before. People still come to you and tell you about problems they can’t solve and ask for your advice. I don’t need bugs to fix. Bugs are old stuff, code from yesterday and fixing it only makes stuff running, that should long be forgotten.

  16. 29/05/2012daGrevis says:

    You are insane person! I like. :)

  17. 29/05/2012nbe says:

    @anon

    That’s easy. An ego-tripping non-.NET developer.

  18. 29/05/2012Dg says:

    The term “test driven development” is stupid. Tests drive development, and tests are driven by requirements, so by the transitive property shouldn’t it be called “requirements driven development”?

  19. 29/05/2012Reynold Chery says:

    Intellectuals solve problems; geniuses prevent them – Albert Einstein.

  20. 29/05/2012Darren says:

    The problem is… *YOU* might enjoy debugging, but your clients and managers pay you to write working software.

  21. 29/05/2012H3 says:

    Debugging your own code is fun, debugging others makes you want to kill yourself sometimes…

  22. 4/06/2012Karlo Smid says:

    Hi!

    In debug mode you stop executing your program, and then you observe it, which is far away from the real, production environment (Heinserberg rule). In production environment, your code does not run in that manner. Code runs without stoppage interruption. Using TDD, you can easily observe your program that runs as in real production environment, without user interruption in order to observe it.

    Regards, Karlo.

  23. 9/09/2012Redd says:

    Been learning python the last few months and I get the same ego trip when I get a break through on one of the tools I’ve been developing! Which my mentor then swoops in and shows me how to do it in half the code thus crushing that happy feeling.

  24. 3/01/2014Ian says:

    You still need to debug code when you do TDD because often your initial attempt at making a test pass will fail.

  25. 9/01/2014Rob Galanakis says:

    Ian: You shouldn’t need to “debug” when you write the failing test. You should know why you’re writing the test you are and then how to make it pass, by looking at the code without a debugger. The exception would be maybe creating a test for a found bug, and then figuring out what the bug is. But even then it should rarely involve the debugger.

Write a comment:


− 5 = two