[Solved] CSCI611 Project 2: Autotesting Gold Chase

Testing Framework project for testing gold chase Game.

SummaryThe 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 necessarycall Map::drawMap() if appropriatecall Map::postNotice() if appropriateRepeat, until user wins or quitsIn addition to interacting with a reimplemented Map class, the driver program should control the map that Gold Chase reads inproviding the game with a map which eases the drivers task of testing the game. To simplify communications between the games reimplemented Map class and the driver, communications should be restricted to two functions: Maps constructor and Maps getKey member function. The constructor is ideal for providing information back to the drivera 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 ProcessThe 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.Dont 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 execd 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.