Is unit testing viable in game programming?

Question

I\'m fond of the idea of unit testing but I\'m having trouble applying it to game programming. Games are highly stateful and often the code doesn\'t break itself into distinct u

Answer 1

Programming is programming. Unit tests are useful for any kind of application because they help you detect and correct errors (and often more importantly, regressions inadvertently introduced as you refactor code) immediately and efficiently.

There are of course areas of high level behaviour that are difficult to unit test, but that's not really what unit tests are for - they are primarily for checking that individual methods or small parts of the codebase do what they are supposed to do.

For the higher level behaviours, you need to apply other testing approaches (regression testing, for example: feeding a fixed sequence of inputs into the game and then checking that you get the same results every time, or generating camera views at fixed locations throughout a level and checking that they always generate the same (or at least a reasonably similar) image)

Your example of PlayerJump is one such case. You can unit or regression test this by isolating it with constant inputs (programatically place the player character at a fixed location in a simple test scene and fire the jump event, then check that his collisions or final resting place is consistent. By building up a library of different objects the player can jump "at", you can cover a lot of test cases (e.g. that the jump succeeds over a gap of the prescribed maximum-jump distance).

Beyond that, though, games do require a lot of gameplay testing (where real users simply play it). This will find odd cases that you didn't cover with automated tests, but more importantly it will answer a question that automated testing will never answer: Does it "feel" right? Is it "fun"? These are tests only a human can conduct.