From: "Daniel" <notdanielt3 / gte.net>
> In the first case, your talking about collision detection. No automated
> test can be devised for that, a person has to look at the screen and
> decide if the ball should have changed directions, or continued on its
> course.

I haved written automatic tests for pixel perfect collision detection of
sprites in a shoot-em-up video game.  It was completely straightfoward:
identify the boundary conditions and then test situations far from the
boundary conditions, and on either side adjacent to the boundary condition.

Note: collision *detection* is a different issue to collision *resolution*,
which defines what happens in response to a collision when it has been
detected. Both can be tested separately, and then the integration of the two
functions can be tested.  In testing collision detection you test that the
collision detector identifies sprites as colliding when they are actually
colliding, and not when they are not. In testing collision resolution you
assume that a collision has occurred and call the resolution method
directly, after preinitialising the colliding sprites to predetermined
states.  Then you test the integration by checking that a collision
resolution function is called when the collision detector detects a
collision between two sprites.  This is done with a a mock collision
resolver object that asserts that the sprites passed to the resolution
method are those that have been preinitialised to be colliding.

Cheers,
            Nat.


________________________________
Dr. Nathaniel Pryce
B13media Ltd.
40-41 Whiskin St, London, EC1R 0BP, UK
http://www.b13media.com

XP Day, London, UK. 15th December 2001. http://xpday.xpdeveloper.com/