Why I hate Test Driven Development
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.
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.)
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.
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!
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
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.
an ego-tripping .net developer, what’s worse?
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.
If you love debugging, you’ll really love TDD. With TDD, you get to debug all your test code.
Awesome reply!
Can’t tell if sincere or just a douche.
Spend your new found time on creating new projects to solve real world problems !
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
What is faster? TDD or debugging?
@blub +1
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.
You are insane person! I like. :)
@anon
That’s easy. An ego-tripping non-.NET developer.
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”?
Intellectuals solve problems; geniuses prevent them – Albert Einstein.
The problem is… *YOU* might enjoy debugging, but your clients and managers pay you to write working software.
Debugging your own code is fun, debugging others makes you want to kill yourself sometimes…
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.
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.
You still need to debug code when you do TDD because often your initial attempt at making a test pass will fail.
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.