13
\$\begingroup\$

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...)

\$\endgroup\$

1 Answer 1

Reset to default
17
\$\begingroup\$

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.

\$\endgroup\$
5
  • \$\begingroup\$ 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. :) \$\endgroup\$
    – CodeSmile
    Commented Jul 30, 2010 at 16:37
  • \$\begingroup\$ 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. \$\endgroup\$
    – Iain
    Commented Jul 30, 2010 at 17:48
  • 3
    \$\begingroup\$ 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. \$\endgroup\$
    – Cyclops
    Commented Aug 7, 2010 at 14:08
  • \$\begingroup\$ 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). \$\endgroup\$
    – Andrew Russell
    Commented Mar 18, 2014 at 12:21
  • \$\begingroup\$ 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. \$\endgroup\$
    – Andrew Russell
    Commented Mar 18, 2014 at 12:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .