Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have been dabling in game development since I started programming, but never very seriously. I work as a business app developer, but I'm working on some games in my spare time.

In the business world (on the Microsft web-dev stack) ASP.NET MVC is becoming really popular, because of its ease of unit-testing the way the interface works.

I'm wondering what design patterns (MVC, MVP, MVVM, etc) one could use to write a game in which all of the game logic is easily unit-testable. Is this possible or feasible? Am I wasting my time, is it better to do full builds and then run "integration" type tests instead of unit-tests?

Sample code would be great, but a writeup is also useful.

(I tried to add a unit-testing tag, but don't have the rep required...)

share|improve this question

1 Answer 1

up vote 17 down vote accepted

Here is a good article that I found that describes an architecture for separating out functionality to make it not only easily reusable, but also potentially far easier to unit-test:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Some games will benefit from a MVC-like pattern. Board games like chess and card games come to mind. In most cases, however, this is massive overkill.

Personally I find it is sufficient to only unit-test things that are algorithmic in nature. Things that you will depend on to "just work" when you're writing gameplay code, and can be insidiously hard to track down problems in, if they don't. Things like intersection tests or networking code.

(Things that ideally will be built into a 3rd party framework so you don't have to write or test them!)

One technique I do like to use for unit testing game-related things is what I call the "visual unit test". The basic concept being a simple line-rendering of the bit of code in question (say for example an intersection function), and some basic key or mouse assignments to manipulate the inputs. No one said unit tests have to be automated - they just have to break things down into individual units and test them.

share|improve this answer
    
Good answer. I also wanted to post exactly that article. Game Object component systems are a great way to seperate logic and be able to unit-test these individually. What no unit test can do, however, are the complex interactions of multiple paths of game logic interacting at realtime in random sequence. That would be like trying to unit test the weather forecast. :) –  LearnCocos2D Jul 30 '10 at 16:37
    
Yeah I also make little testers that isolate particular bits of functionality. I make sure whatever changes I make to APIs etc I always make sure these still work. Much easier to reuse the functionality in your next project. –  Iain Jul 30 '10 at 17:48
3  
Yes, good answer, and I like the link. And I agreed with everything up to the last line, "No one said unit tests have to be automated". :) Have to, maybe not - but everything I've read implies (or says outright) that unit tests should be automated, to the point where you only push a single button to run all of your tests. Otherwise, the more work involved in running the tests, the less likely you are to run them often enough. Granted, if you're talking about display code, it can be much harder to unit-test, if even possible. –  Cyclops Aug 7 '10 at 14:08
    
Nearly four years on, and I feel I've developed a better understanding of why the "visual unit test" works so well: Unit tests are a development tool. A typical automated unit test can tell you that something is broken. But a visual unit test can let you explore very complicated algorithms and help you quickly identify why something is broken (particularly when combined with live code editing). Often a visual test can identify issues that you'd otherwise have to anticipate to test with code, or issues where there is no "right" answer (eg: tuning). –  Andrew Russell Mar 18 at 12:21
    
And the idea that unit tests need to be run "often enough" (as in: always, in an automated way) is bogus. Code that doesn't change obviously doesn't need to be re-tested. And when the code is being modified, the developer doing the modifications should be doing so while utilising the appropriate available tests (visual, code-based or otherwise). Obviously there exists code with a certain risk profile where an automated test is a worthwhile time investment. But such scenarios are especially rare in game-development. –  Andrew Russell Mar 18 at 12:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.