Re: [GD-General] Unit tests

[Chris R. <c....@gm...>]

I found unit-testing cumbersome as soon as you come to debugging your
unit-test code.=20

As soon as you come to terms with more abstract and highlevel design
aspects of your engine, the time and effort spent in unit-testing (for
us at least) did not outweigh the benefits.

For low-level (math-, mesh/geometry-, animation related functionality,
where behaviour is well defined and results can be checked easily) there
was a huge benefit as unit tests resulted in catching code changes
breaking existing code paths.

For high level, abstact functionality we abandoned the unit test
approach and implemented a nightly build script, which checked if the
engine would compile and would load all finished content and compare the
standard output against wanted results (e.g, it would send a mail to all
developers if the word "error:" appeared in the output while loading the
content).

This of course did not catch the bugs when the content was displayed
incorrectly, or if other functionality was broken (e.g, ai behaving
wrong, renderer displaying strange images), but these bugs cannot be
caught by unit tests either but by a developer who tests his code
extensively by running it and looking at the results.=20

just mho and my 2 cents,=20

regards,=20
Chris=20



On Thu, 2004-10-14 at 19:28, Jason Bay wrote:
> I'm very curious to explore how (or whether) the XP-stoked unit test=20
> paradigm can work in games. Are any of you are using automated unit tests=
 in=20
> your game engine? If so, do you have any suggestions to help me along? Ca=
n=20
> you point me at any printed or online resources about unit testing that=20
> would apply to real time games?
>=20
> I've been making a concerted effort lately to work some small automated=20
> tests into our game engine code to do simple things like checking for=20
> alignment of related tables, checking math-related functions, etc. So far=
,=20
> it's been limited to a group of special test functions that get run when =
the=20
> game is launched, and which will assert if anything goes wrong.
>=20
> But I'm at a loss as to how go about constructing unit tests for most of =
the=20
> game functions, such as menu navigation, interacting with AI, etc. It see=
ms=20
> like this would require me to write some kind of module to simulate user=20
> input (cursor moves, button presses, etc.) and I'm not sure how I could=20
> possibly write something that could come close to simulating the input=20
> patterns of a human. Plus, I'm writing for resource-limited handheld=20
> consoles (currently the Nintendo GBA and DS), so I can't really use a=20
> separate app to poke at my game while it's running, as I might be able to=
 do=20
> on a PC.
>=20
> If you have any suggestions, anecdotes, or resources, I'd love to hear th=
em.
>=20
> Jason Bay
> Griptonite Games
>=20
> (P.S. I sent this message earlier in the week, but it didn't appear to sh=
ow=20
> up on the list. My apologies if this turns out to be a duplicate.)
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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 mo=
re
> 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=3D557
>=20