RE: [GD-General] Unit tests in a game engine

[Hutchison, B. <Ben...@se...>]

ad...@li...] On Behalf Of
> Jason Bay
> Subject: [GD-General] Unit tests in a game engine
>=0D
> I'm very curious to explore how (or whether) the XP-stoked unit test
> paradigm can work in games. Are any of you are using automated unit
tests
> in
> your game engine?=0D

I have been using unit tests in "game-like" simulation software written
in Java that has user interface, using JUnit. I'm happy with the result.
Note that I wrote the tests as I wrote the software, not added them
later, and this makes things *much* easier.

If so, do you have any suggestions to help me along? Can
> you point me at any printed or online resources about unit testing
that
> would apply to real time games?

My experience has been that writing units tests is very hard when you
start, in any domain, and you just have to keep trying, incrementally,
to get better at testing (and writing test-able code). In terms of refs,
for starters, Martin Fowler's book and online articles have been a vital
guide for me.

The single best piece of advice I've heard recently re: testing is
"Every time you discover/fix a bug, write a unit test to detect the
buggy behaviour". Stop the bug re-surfacing, but also tends to reveal
error-prone parts of your system as a side effect.=0D

And I'll just restate the essential idea of a test. Start with a system
in a known, static state. Perform one or few test-controlled operations
on that system. Manually work out what the expected correct post-state
is (which can involve pen, paper and calculator), and then assert the
system is in that state.

>=0D
> I've been making a concerted effort lately to work some small
automated
> tests into our game engine code to do simple things like checking for
> alignment of related tables, checking math-related functions, etc. So
far,
> it's been limited to a group of special test functions that get run
when
> the
> game is launched, and which will assert if anything goes wrong.
>=0D
> But I'm at a loss as to how go about constructing unit tests for most
of
> the
> game functions, such as menu navigation, interacting with AI, etc. It
> seems
> like this would require me to write some kind of module to simulate
user
> input (cursor moves, button presses, etc.) and I'm not sure how I
could
> possibly write something that could come close to simulating the input
> patterns of a human. Plus, I'm writing for resource-limited handheld
> consoles (currently the Nintendo GBA and DS), so I can't really use a
> separate app to poke at my game while it's running, as I might be able
to
> do
> on a PC.

You are probably experiencing the difficulty of retrofitting tests to
code. I don't test my UI much, but I do test AI, movement and the like
during play, by making the same code calls that the UI does. I firmly
think that is the best approach. It sounds likes there some tight
coupling, or even interweaving,  between you UI "view" and your game
"model", that might prevent you doing this.

I do test small pieces of my system in a stripped down mode. Unless the
scope of the test is small, I have canned micro-levels that are really
small and simple that I can test unit actions or AI in. But I think
testing pieces is hard if you wrote the code first; I changed my design
a lot to accommodate easy unit testing.

One of the hardest problems I had was testing things involving
randomness from random generators. After much wrangling, I settled on a
preferred approach of substituting in "Mock Randomizers", which were
hard coded to produce a certain output value or pattern. Then I'd work
out what the code should do in response to those numbers
(time-consuming), and assert my expectations in the test.

I write my tests soon after first version a class, and update them if I
add major new functions, or if I later find a bug in the class
(following my earlier rule). My tests often fail, and I don't move on
til they pass. Sometimes it takes a week to get a class working that
took a day to write.

The payback for all this work comes when you put everything together as
a full simulator. It just works! Not quite, but I have found noticeably
few bugs while actually running my sim.=0D

Finally, if you want to have a really positive unit testing experience,
it's more likely to happen when you build your tests into new code. That
is, when you next start a project, or even a new subsystem or component,
write a test on your first day, even if trivial, and stick to the habit
throughout its development.

Regards
Ben Hutchison

www.sensis.com.au

A leading Australian advertising, information=0D
and directories business.=0D

www.yellowpages.com.au
www.whitepages.com.au
www.citysearch.com.au
www.whereis.com.au
www.telstra.com.au
www.tradingpost.com.au

This email and any attachments are intended only for the use of the=
 recipient and may be confidential and/or legally privileged.
Sensis Pty Ltd disclaims liability for any errors, omissions, viruses, loss=
 and/or damage arising from using, opening or transmitting this email.
If you are not the intended recipient you must not use, interfere with,=
 disclose, copy or retain this email and you should notify the sender=
 immediately by return email or by contacting Sensis Pty Ltd by telephone=
 on [+61 3 8653 5000]