unit-testing - what - when to unit test

XNA Unit Testing (6)

So I'm interested in hearing different thoughts about what is the best way to go about unit testing XNA Game/Applications. Astute googlers can probably figure out why I'm asking, but I didn't want to bias the topic :-)


This book shows how to code in XNA but the entire book is based on NUNIT testing. So while you are coding the projects in the book, he also shows you how to write the scripts for NUNIT to test the XNA code.

If you would like to have a dynamic provider/server for your resources you have a whole bunch of possibilities. With C# you could use f.e. WCF to provide your Resources. But as mentioned before maybe you should try to decouple your design so that you can actually use unit testing instead of starting the whole game.


VS2008 has a nicely integrated unit testing framework. (I assume you're using using the XNA 3.0 CTP with your Zune.)

Access objects from another process

If you want to unload an reload compiled dlls full of resources then you may want to look at Application Domains. i.e. you can unload and reload assemblies with it. But you have to access their contents via a "proxy". You cannot unload assemblies directly, which is why you need domains.

The idea would be to load up a master application that never closes. Then you have a seperate Game.dll that you load up in its own Application Domain. You then load all your resources in your master application. So you would need to make a "proxy" interface for the game to get hold of the resources, but that should be doable.

The good thing about this is that you stop your game.dll, recompile it, reload the assembly and give it the still loaded resources.

One possible route.

Accessing a XNA ContentManager in a unit test?

Unit testing an XNA project is a common issue and one that is often discussed. Usually, the problem is due to either needing access to an instance of either Game, GraphicsDevice, or (in your case) ContentManager, and there not being any easy way of obtaining one.

You can see related discussions here, here, and here.

I believe the generally accepted practice is to re-evaluate what you are trying to test to see if you actually need these references, or if you can find a way around them.

Failing that, could your test case be sufficiently covered by playtesting?

If neither of the above apply, mocking the objects can prove to be rather difficult due to the requirements placed on them by their parent classes/interfaces, but I have heard of people doing it. I have also heard it is possible to actually create a GraphicsDevice using an invisible form, but I have not done this myself.

For my own tests, I've gone with not testing any graphical elements (Drawing, Resource Loading, etc.). It does leave a bit of a hole in my code coverage, but after spending a few days searching for ways of solving this exact problem, and not finding any answers, I decided testing my library functions (which do the majority of the work in my projects anyway) was good enough.