Unit testing can create some problems when working with GUI applications, like an XNA game.  How do you verify that something looks right when you're running automated tests?

I've been working with building a simple game engine (so far I've got sprite rendering, collision testing, quadtree culling, and a Lua console) and I bumped up against the unit test problem.  I'm afraid I attacked it from the wrong direction.  I started with some automated tests, but I started to devolve into using a patchwork system of visual (non-automated) unit testing.  It's my plan this weekend to go about and fix the issues I've encountered.

Lessons learned:

You should generally only visually test (as an independent test) the elements of your application that actually involve drawing.  I failed this by creating a test that simply draws my sprite (a valid use of the test), then creating another that updates the sprite's properties.  Updating properties and other non-visual changes should be tested in automated tests; you'll be much more productive.  The only time you should create a new visual test when you're testing something new about the drawing process.  Assuming your automated tests passed okay (and that you are testing for the right things), your visual tests shouldn't care about whether the same code was done properly, only that the rendering looks okay.

It's just been one of those weeks where you start thinking along one line, get distracted, and before you know it, you're lost in the urban wilderness.  :-P

Cheers!

Devan