TDDXNA

20 03 2011

Lots of letters…

As I’ve said before, using test driven development and unit tests on an established framework (XNA in this case) is fairly futile. I guess it can be done if I put my mind to it and lots of time to figure out how to mock every single aspect of the framework but I don’t think it’s worth it. In the end I have to trust that the framework does what it says it does and have my asserts, preconditions and postconditions act as the live tests for it; after all that’s what they’re there for.

Writting the sprite classes as data stores which describe the drawing/loading states of the actual images did prove to be the right course (so far anyway). It makes the code more natural to read and it allows me to apply these descriptions to multiple textures at once. The next module I’m going to throw myself at is the input and game commands, wonder how that’ll go?

Short post today, I’m sick and so is my little one…

“Lady Startdust sang his songs of darkness and dismay”

Advertisements




And I’m back!

16 03 2011

So, I’m not dead, not yet anyway; let’s just say I took a very looooong vacation. Which is a lie since I never take vacations and I’ve actually started full time work, but hey I’m allowed to dream.

The last time I’ve seen this blog it was actually still 2010 and I was writing tests for a timer class which is long been tested to death and it works… Honest… Trust me… Okay, alright, I’ll post the rest of the in the next couple of days once I reorganize and try to remember what the hell I was talking about. In the meanwhile I’m also glad to report that I’ve picked up two other projects to work on, both sort of have to do with Microsoft’s Dream.Build.Play (rather than Dream.Build.Debug which is a completely different thing altogether) and the upside of that is that I get to work with C# (which I have grown to love in the last few months) and XNA (which I have grown to like in the last two weeks). Well, being the lovable programmer that I am the first thing on my mind is, you guessed it, TDD!

And you know what, XNA is not the friedliest framework for tests as I’ve discovered, at least from what I’ve gathered by trying a few bits and reading up online. See the problem with a framework and the concept of Unit Tests is that I don’t think they mash together quite perfectly. Unit tests rely on nothing but the classes, frameworks force complience on everything they have and the kitchen sink (actually XNA isn’t that bad, I’ve seen worse, much much worse).

Let’s put things in perspective.

One of the projects in question to use XNA is a 2D platformer type thingy, which I won’t go into much detail since I’m not really at liberty to say much at the moment. I’ve been nabbed on Sprite duty. XNA comes with a lot of built in functionality for loading and drawing pretty 2D pictures via the ContentManager and the SpriteBatch objects and having a central object to hold all the nice data and functionailty will be really nifty; enter the mighty Sprite class. Let’s TDD!!

class TestNewSprite
{
  [TestMethod]
  public void name_is_NewSprite()
  {
    Assert.AreEqual("NewSprite", _sprite.Name); 
  }
}

Wooh, so many things that break on that it isn’t even funny. For the rest of it you’ll have to imagine me building the code backwards.

class TestNewSprite
{
  public TestNewSprite()
  { 
    _sprite = new Sprite("NewSprite"); 
  }

  [TestMethod]
  public void name_is_NewSprite()
  { 
    Assert.AreEqual("NewSprite", _sprite.Name); 
  }

  private Sprite _sprite;
}

Alright, I know the drill; create the class, create the fields and watch everything go green. Now what?

My first thought was a Sprite needs an image. Basic right? I mean, the whole point of it is to wrap a texture and describe how to draw it with extra data… Wrong! This is basically where I hit a brick wall. A Texture2D object requires the XNA framework to load, meaning I would need start fiddling around with mocks and manually instantiating the parts of the framework which I need. While these things are possible, and in fact have been done by a couple of other people on the ‘net, it just doesn’t strike me as a unit test, intergration test – yes, but not a unit test. So after some thought and talking to myself while doing the dishes I’ve decided to change my perspective on the problem.

I’ll TDD my Sprite class as a data set which describe the drawing behaviour to apply on a texture. The class will hold a reference to a texture which will be created by a ContentManager object but I’ll not test that particular functionality, I’ve got to trust XNA that it works right?

I’ll most likely wrap XNA’s concept of a ContentManager in my own custom object which will automate the loading of a texture using the Sprite class data. And as for drawing; same thing. I’ll wrap the SpriteBatch in an object which will know how to use the Sprite, SpriteMap and whatever else I’ll think about and joy to the world. Unit tests will ensure not only that I only have the data I need but that all my assumptions about manipulating it [like scaling, moving, etc.] will be correct.

Since I haven’t yet tried it I don’t know if it’ll work but I suspect that it will. I’ll write up a self-review tomorrow after the first attempt.

“Though I do like breaking femurs, You can count me with the dreamers”