How to properly test different aspects of your game

Hey all,

So I'm currently working on my 1st "sizeable" project (by that I mean one that is not just for toying around) and so I'm starting to think of how to effectively going about testing. Currently, I'm still in the experimental phase where I'm just trying to decide the features I need for my game and how they will all fit together. I'm thinking that, realistically, if I really want to go about 'officially' testing anything then I need to get my api's somewhat solidified. So in the meantime I'm just fixing bugs as I go along. In a way I think this counts as a testing phase as my code is constantly getting interacted with and used in different ways which brings up more bugs to fix naturally. Though some of the bugs are starting to get difficult to pin down and can take longer than I would like. I guess my question is what exactly are the best practices for testing your game? For the experimental stages do you essentially do what I've been doing and just really on whatever current debugging tools you have and fix things along the way and then once you feel your api's are pretty solid you start performing some unit tests/integration tests where applicable? If so, what sort of integration tests do you do for games? Right now that term seems sort of vague so not sure exactly what goes into an integration test.

Edited by Jason on Reason: Initial post
boagz57
For the experimental stages do you essentially do what I've been doing and just really on whatever current debugging tools you have and fix things along the way and then once you feel your api's are pretty solid you start performing some unit tests/integration tests where applicable?


In my opinion, in a game there isn't much test you can automate. Testing things that are related to user input / behavior is very hard, it would take a lot of time and effort for probably not much result (never done it so it's just my guess). If you want to find bugs in a game you need testers and you need to give them the tools to properly report issues (describe what you want in the report, have a button to report a bug in the game, have the game capture information about it states and possibly a screenshot).

I just debug problems as they come. Sometimes I add some code to validate the state of some data structure to make sure it doesn't get corrupted. But if the data structure changes it's more code to keep up to date and debug.

boagz57
Though some of the bugs are starting to get difficult to pin down and can take longer than I would like.


If you can identify a "pattern" in those bug it might be possible to change you coding style (the way you think about API or approach a problem) to prevent those bugs or make them easier to fix.

You may also want to add some tools in you codebase to help you debug (logs, a way to graph/visualize data, save states, memory dump, image dump, profiler...). Asserts help a lot.

But some bugs will just take time to track down.


If you google Casey Muratori's blog posts on testing the walk system in The Witness (the "walk monster"), you may find some good food for thought. I think his approach there is more suitable for testing aspects of your game that are mostly done and you just want to polish. Then again, maybe it's not worth putting a lot of effort into testing before that point anyway. :-)
Aright cool, thanks for the suggestion. I will check it out.

Edited by Jason on