Game Development Reference
In-Depth Information
Your inputs are recorded as you play the game and at various points you designate,
screen images are captured for comparison whenever you “replay�? the test in the
future. This is well suited to the graphical nature of videogames.
Capture/playback testing adds a slight overhead to running the test manually the first
time. At various points during your manual testing you will need to guide the test tool
to capture the game data and screen elements that must be checked by the test. This
investment pays off when you can automatically play back the tests every time after
that. Maintaining the tests is expensive when the game features being tested are unsta-
ble. Time is wasted on implementing, reviewing, and managing changes that are only
good for a few test runs. In that case, you should postpone automation until the
requirements, design, and code are stable.
Vermont HighTest
™
(VHT) is a capture/playback test product that was used for the
examples in this chapter. The topic's CD-ROM includes a link to the VHT Web site
where you can download a 30-day demo of VHT as well as a User's Guide. Each VHT
“test�? consists of database files containing data captured during recording and a doc-
ument file containing the test code. Log files (documents) are created each time the
test is run.
Recording
You should have some idea of what you are going to record and test for before you
start automating. You can use tests that are produced by the various design method-
ologies described elsewhere in this topic or test scripts that have been in your family
for generations. In either case, you need to define or plan ahead of time which screen
or window elements you are going to check (capture) in order to establish that the
game is working right.
You start recording a test in VHT by selecting New from the Record menu or by press-
ing F11. During recording, a Record Bar window appears on your screen as shown in
Figure 17.1. The icons in the first row of this window are used to capture various types
of screen contents such as the entire screen, a specific window, or a region that is
defined by the tester during recording. The icons in the second row are used to add
comment or control statements to the test as it is being recorded. The stop sign icon
in the third row is used to suspend recording.
Another way you can use the capture function is to record ad hoc and playability test-
ing. The test can't detect problems it's not programmed to look for, but you can pause
at any time to capture interesting windows or screen images to show to skeptical
developers. The recording can be used to see what steps got you to the problem spot.
