views:

413

answers:

3

I'm fooling around with the XNA framework.
To help me around I made a helper class that looks like this:

ActorHolder
+ SpriteBatch (SpriteBatch)
+ ContentManager (ContentManager)
- drawables (IList<IDrawable>)
- updatables (IList<IUpdatable>)

+ ActorHolder(GraphicsDevice, ContentManager)
+ Draw(GameTime)
+ Update(GameTime)
+ AddActor(IActor)
+ RemoveActor(IActor)
+ GetCollidingActors(IActor)

Now I want to unit test this class. But as you see my constructor needs a graphics device and a contentmanager. While I think this makes sence in my application, it doesn't in my tests.
Should I mock these two just in order to unit test or is my design flawed?

--UPDATE--
I found a link to a project that might help out: http://scurvytest.codeplex.com/ Don't have any xp with it yet as coding has to make room for social life a bit.

--Note--
Excuse me my UML French, my company doesn't use it so I never used it except back at school.

+2  A: 

This seems like a very valid usage scenario for mocking. I don't think there is a flaw in this design -

One reason mocking exists is to help with filling in resource requirements of an interface that are not available at testing time, such as remote objects, or in your case, the graphics resources. Mocking the graphics device and content manager seems appropriate here, to me.

Reed Copsey
THanks. I'm still pretty new to unit testing (not allowed to use it at work :S)
borisCallens
The problem is that there is no IGraphicsDevice. It's a concrete class. Period :S
borisCallens
Yeah - it's pretty nasty to handle, though - you still can wrap it into another class that also defines your interface, and then mock that interface... but it's a pain.
Reed Copsey
A: 

As I discovered from my other question, GraphicsDevice is not to be taken lightly. This discussion on XNA community forums in particular points out why it is not a good idea to mock this out.

I am still searching for a good solution to this. However I am inclined to think that either:

  • it's a design flaw in my architecture (i should decouple my components more)
  • it's a design flaw in the XNA
drozzy
The silly thing is that at some point I found a codeplex project that made unit testing XNA possible. And then I forgot to bookmark it.. If I find it again, I'll make sure to note it down here...
borisCallens
+3  A: 

I am "mocking" the graphics device by actually creating a real one on an invisible window. Performance is surprisingly good - 12 seconds for about 1500 tests.

It allows me to test code which requires a graphics device and do some basic verification (eg. is the right texture set, has the vertex buffer been selected, etc.). This could be improved by using the reference rasterizer with the DirectX Debug Runtime to do more intensive checking.

If I need to verify what gets sent to the graphics device, I create an interface through which the code-under-test can send the vertices - which can then be easily mocked with standard mock object frameworks.

Check this question for another discussion about mocking XNA graphics device dependent classes: Mocking Texture2D

Here are the classes I'm using to "mock" using a real graphics device: MockedGraphicsDeviceService.cs, MockedGraphicsDeviceService.Test.cs

Cygon
Rather late answer, but this reminds me I should continue on this project again :P
borisCallens