Description
Testing Framework project for testing gold chase Game.
Summary
The purpose of the second project is to develop a driver program that will automate evaluation of the Gold Chase game. The driver will automatically start two game processes (that is, two players), provide input to the game processes, and evaluate the game output for correctness. To facilitate the automation, the implementation of the Map class will be replaced with code that writes/reads game data that the driver program evaluates. As a first step to understanding where the Gold Chase game could exchange information with the driver program, we need to identify the points where the game currently interacts with the
Steps in Map class:
Open mymap.txt (or some other filename), read in the number of fools/gold and the lines of the map.
Call Map constructor, e.g., renderer=new Map(mapMemory->board,rows,cols);
Call Map::getKey()
interpret input, update shared memory if necessary
call Map::drawMap() — if appropriate
call Map::postNotice() — if appropriate
Repeat, until user wins or quits
In addition to interacting with a reimplemented Map class, the driver program should control the map that Gold Chase reads in–providing the game with a map which eases the driver’s task of testing the game. To simplify communications between the game’s reimplemented Map class and the driver, communications should be restricted to two functions: Map’s constructor and Map’s getKey member function. The constructor is ideal for providing information back to the driver–a kind of initial handshaking to confirm that everything is working properly. The getKey member function should pass information regarding the current state of the game. The other two member functions (drawMap and postNotice) can simply maintain counters of number of times called. These counters could then be passed to the driver as part of the state information that getKey provides.
Steps in GoldChase Game Process
The driver must be able to read from, and write to, a game process. Since a pipe() command creates a one-way pipe, create two pipes for a game process.
Fork the process.
Don’t forget to have child and parent close all unnecessary file descriptors. Once the pipelines have been prepared between the parent and child, the game can be exec’d in the child. The parent must now have the complementary behavior to that of the child described in the numbered list above:
Open mymap.txt (or some other filename), write out the number of fools/gold and the lines of the map. Close.
Read the rows, columns, and map from the game process (sent from Map::Map). Confirm expected values.
Read the “draw map” variable, “post notice” variable, and map from the game process (sent from Map::getKey). Confirm values are as expected (if necessary). Decide on what the next move should be and write a character to the game process.
Repeat #6 until test(s) are completed. If necessary, write a ‘Q’ to the game process to end it.
Note that the above description must be expanded to handle two game processes.
