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.

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.

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

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

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

Awesome reply!

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.