Re: [GD-General] Unit tests

[Kent Q. <ken...@co...>]

Much testing can be done if you architect the application properly. In 
particular, it's very useful to create a very thin interface through which 
all variable input flows. This includes:

* Keystrokes
* Controllers (mouse, joystick, touchpad)
* Timing information
* Random numbers

You can then record and play back this stream to provide certain types of 
tests (as well as a handy macro capability).

You can also write simulators which can act like anything from random 
banging on the keyboard to structured testing.

On the other side of the same interface, you can write a simulator that 
checks to see if your input functions are generating the expected results.

If you're also careful to separate your user interface using some sort of 
pattern like Model-View-Controller, it becomes possible to write a View 
that has no graphics and simply reports results. This gives you the ability 
to record and play back user interface code without having to watch a screen.

And so forth. I must confess I've never successfully implemented all of 
this. Different bits on different projects, yes. But priorities vary per 
project.

Don't forget that most internal functions have no user interface and can be 
independently tested if you're clever about it.

         Kent

At 01:28 PM 10/14/2004, you wrote:
>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? 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?
>
>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.
>
>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.
>
>If you have any suggestions, anecdotes, or resources, I'd love to hear them.
>
>Jason Bay
>Griptonite Games
>
>(P.S. I sent this message earlier in the week, but it didn't appear to 
>show up on the list. My apologies if this turns out to be a duplicate.)
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Gamedevlists-general mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=557

----
Kent Quirk
CTO, CogniToy