TDD (Test-Driven Development) can be great. It encourages you to address edge cases earlier when you have a better grasp of the code you just implemented. It forces you to de-couple classes in ways that allow you to later combine and re-use them in ways that might not have been possible had you developed them using other methodologies.
TDD can also be a big pain-in-the-ass. Isolating logic for testing can be difficult, especially when you need to rely on code that requires complicated external resources: legacy codebases and hardware being the prime examples. The XNA Framework code, with its substantial functionality abstracting the details of hardware on Windows, the Xbox 360, and Windows Phones, falls squarely into both of those categories.
So, does this mean that it’s impossible to use TDD when working with XNA? Hardly. It can be tough, but there are ways to make it easier. In this post, I’ll talk about how I’ve managed to work with XNA while still giving my code the TDD-loving it deserves / needs.
TDD (Test-Driven Development) can be a hard-sell in many work environments. I said as-much in a previous post. The main problem lies in figuring out how to calculate the concrete time costs of TDD versus the abstract (but real) benefits.
While it’s easy to track the costs of TDD with a timesheet recording the amount of time spent writing tests versus production code, measuring the benefits in a measurable way takes a bit more creativity. My approach to measuring the benefits of TDD in my own code is to keep a journal of moments of when I think I have reaped benefits due to TDD. This is, of course, a very anecdotal approach to measuring the benefits, but it does provide a basis for tracking effects of TDD that would normally go unmeasured.
I’ve had an infatuation with test-driven development (TDD) for years but I’ve never had a chance to use it professionally to any major extent. While the potential benefits of TDD, like reduced bug regression and greater code decoupling, are substantial, the considerable cost involved in learning how to write effective tests and testable code make it a hard-sell to introduce in many work environments.
I can sympathize with a manager who is cautious about adopting TDD, compared to the very palpable up-front costs, the benefits tend to be future-oriented and hard-to-measure. Luckily, I don’t have to worry about convincing managers to let me try TDD for my personal projects. This gives me a chance to give TDD a test-drive (bad pun, I know) and see just how it affects the code I write. Being that I’ve been working a lot with XNA lately, I’ll demonstrate a method to integrate the NUnit unit-testing framework with Visual Studio 2010 Express in order to practice TDD while using XNA.