White Box Testing

"White Box" Testing

In contrast to black box testing, white box testing gives the tester an opportunity to exercise the source code directly in ways no end user ever could. It can be a daunting challenge for a white box tester to read a piece of game code and predict every single manner in which it will interact with every other bit of code, and whether the code has accounted for every combination and order of inputs possible. Testing a game using only white box methods is also extremely difficult because it is nearly impossible to account for the complexity of the player feedback loop. There are, however, situations in which white box testing is more practical and necessary than black box testing. These include the following:

• Tests performed by developers prior to submitting new code for integration with the rest of the game

• Testing code modules that will become part of a reusable library across multiple games and/or platforms

• Testing code methods or functions that are essential parts of a game engine or middleware product

• Testing code modules within your game that might be used by third-party developers or "modders" who, by design, could expand or modify the behavior of your game to their own liking

• Testing low-level routines that your game uses to support specific functions in the newest hardware devices such as graphic cards or audio processors

In performing white box testing, you execute specific modules and the various paths that the code can follow when you use the module in various ways. Test inputs are determined by the types and values of data that can be passed to the code. Results are checked by examining values returned by the module, global variables that are affected by the module, and local variables as they are processed within the module. To get a taste of white box testing, consider the TeamName routine from Castle Wolfenstein: Enemy Territory :

 const char *TeamName(int team) {      if (team==TEAM_AXIS)           return "RED";      else if (team==TEAM_ALLIES)           return "BLUE";      else if (team==TEAM_SPECTATOR)           return "SPECTATOR";      return "FREE"; } 

Four white box tests are required for this module to test the proper behavior of each line of code within the module. The first test would be to call the TeamName function with the parameter TEAM_AXIS and then check that the string "RED" is returned. Second, pass the value of TEAM_ALLIES and check that "BLUE" is returned. Third, pass TEAM_SPECTATOR and check that "SPECTATOR" is returned. Finally, pass some other value such as TEAM_NONE , which makes sure that "FREE" is returned. Together these tests not only exercise each line of code at least once, they also test the behavior of both the "true" and "false" branches of each if statement.

This short exercise illustrates some of the key differences between a white box testing approach and a black box testing approach:

• Black box testing should test all of the different ways you could choose a test value from within the game, such as different menus and buttons . White box testing requires you to pass that value to the routine in one form ‚ its actual symbolic value within the code.

• By looking into the module, white box testing reveals all of the possible values that can be provided to and processed by the module being tested . This information may not be obvious from the product requirements and features descriptions that drive black box testing.

• Black box testing relies on a consistent configuration of the game and its operating environment in order to produce repeatable results. White box testing relies only on the interface to the module being tested and is concerned only about external files when processing streams, file systems, or global variables.