\hypt{bug:negres}{JE}& 3/23/12 & 4:00 PM & State erroneously allows more research to be performed than the current money, resulting in negative money. Moreover, it allows for negative research to be performed, which would provide a way to generated money. & This bug was found on the alpha release. It was found by running the Python unit test $$\verb+test_research()+$$ in the class$$\verb+/src/tests/test_state+$$ The assertion failures catch and describe the bug with a specified message.\\

\hypt{bug:button}{JE}& 3/26/12 & 11:00 PM & The right arrow button on the map display disappears & This bug was found on the March 26 prototype release. It was found by launching the game, then New Game $\rightarrow$ Build $\rightarrow$ Power $\rightarrow$ Windmill $\rightarrow$ Buy $\rightarrow$ End Turn. Then click on the icon of the windmill on the map and the right button disappears. Notice, however, that it disappears only for that block (which you can tell by selecting the icon of any of the other blocks)\\

\hypt{bug:loadFalse}{EC}& 4/02/12 & 11:30 PM & The game just creates a new game and starts there without providing an alert that the user was unable to load or giving the user a second opportunity to load a game. & This bug was found by attempting to load a game that does not exist, i.e., one that was not previously saved.\\

\hypt{bug:refreshBlock}{EC}& 4/02/12 & 11:30 PM & The map blocks do not reset to block 0 or whatever the correct block is for the saved game. & This bug was found by starting a new game or loading a previously saved game after beginning progress on a new game and switching blocks. The block that was open in the new game is the same which is open after these actions are preformed. However, the menus are reset and any open ones are closed upon either of these actions. \\

\hypt{bug:skipinto}{JE}& 4/03/12 & 1:00 AM & The introduction scene can be skipped by starting a new game, going back and then resuming. Essentially, the scene can be truncated since resuming does not take the progression of the scene into consideration. & This bug was found in the most recent release of the game by doing: New Game $\rightarrow$ [Left arrow] $\rightarrow$ Resume. This will bring the player to the main screen, thereby skipping the remainder of the introduction scene.\\

\hypt{bug:outOfMemory}{EC}& 4/09/12 & 11:00 PM & The game runs out of memory by building one object and then continuously clicking end turn. & This bug was found in the April 10 Prototype by clicking New Game $\rightarrow$ Clicking through intro $\rightarrow$ Clicking through tutorial $\rightarrow$ End Turn (many times quickly). Pygame crashes with error message Pygame.error Out of Memory. Repeating this also gives various chains of updates where it crashes with the same error. \\

\hypt{bug:skipTutorial}{EC}& 4/09/12 & 11:00 PM & The tutorial can be skipped by using the left or right arrow keys to switch map blocks. & The bug was found in the April 10 Prototype by clicking New Game $\rightarrow$ Clicking through intro $\rightarrow$ [Left arrow] or [Right arrow]. This will bring the player to the main screen, skipping the entire tutorial.\\

\hypt{bug:emptyMenuPage}{RT}& 4/16/12 & 4:00 PM & If the number of buildings in a build category is an even multiple of the page size there will be an extra blank page at the end. & The bug was found in the April 17th prototype by clicking [Right arrow] $\rightarrow$ [Right arrow] in the vehicles menu with a page size of 2.\\

One high risk area of our program is the State class because it handles the calculations for all of the game logic. It has to determine which buildings can be built based on thresholds as well as calculate changes in the stats based on the Building that was built. Other high risk areas include the Window and WindowEntry classes because everything that is displayed on the screen is part of a Window and each Window is made up of possibly several WindowEntry objects. Since each WindowEntry is made up of a combination of images, rectangles, and text they are mostly unique and a bug that shows up in one might not show up in another. Additionally, the WindowEntry class determines what response should be sent based on where a click occurs, which is a vital component of the user interface. The Game class is high risk because it handles the parsing of responses and determines which methods need to be called to complete the desired task. Furthermore, the Map and Block classes include a lot of hand-coded resizing and dynamic changes. Thus their implementation is risky and should be tested rigorously and together since they work intimately and exclusively together. Similarly, TurnMenu has high risk because it must dynamically compute what options should be available in a particular menu at run-time and then construct such a menu. Thus the reliance on this class to provide the necessary Window containing a requested menu exposes the program to the risk of the class's correctness in its computations.

To test the system as a whole, we will continuously and relentlessly play our game. This will function to expose any errors that become apparent to a player over the course of extended use. We will explore new routes each time and test new features from the user standpoint as they are added. Essentially, we will test the entire software as a whole by approaching it like our players will and note the bugs that arise. Since every possible sequence of moves cannot be simulated, we will play extreme cases like only buying/researching in one category and technology, trying to do poorly in the game, and rigorously exploring new elements as they are added to the game.

The purpose of this test is to ensure that our game can be properly save and loaded given various states and progress in the game. We will test this both by loading a game before playing at all and also by loading a game while we have already made progress in a new game. We will check what block the map appears on and if any of the menus are open when the game was saved. Because of this, we will also trying saving a game after loading a new one and without first loading a new one. We will try to overwrite previously saved games, and also check what happens when file names contain odd, or invalid characters, such as @*(, have names that are too long, and when these names contain spaces. We will also check loading an invalid name. This will be a black box test because we do not need to know how the games are saved or loaded. It will also be a regression test because we want to make sure that previously saved games would not be lost and that we still have this functionality as our game becomes more complicated.

The purpose of this test is to ensure that State correctly updates as it interfaces with the Specs and Building classes upon adding a building. This is a key component to the game logic as a player progresses. Moreover, it is complicated because it involves changes to States due to choices made in the most recent turn and choices made throughout the entire game. Since this ultimately keeps track of the player's game, we want to rigorously test its calculations and its integration with the other classes used to retain data. This will be a white box test because we will observe the arithmetic used in updating values to try to find boundary cases, such as negative values, in order to test the correctness of our implementation. This will be a scripted test where we will create a number of different States and simulate both different changes to the game and the effect of multiple turns elapsing, while at each step checking the current State with the expected State. This will be a regression test that we will run as new States or building types are added, ensuring that the method works as it should under such changes and that the game logic is robust regardless of other implementation changes.

The purpose of this test is to ensure that State correctly updates as it interfaces with the Specs and Building classes upon performing research. This test is very similar in spirit to the \verb+addBuilding+ test, but since it receives a raw value representing how much to invest, it also tests more boundary values. In particular, it checks if the research exceeds the amount of money available, as well as if the amount to research is negative, which would allow the player to generate money.

This test is designed to ensure that buildings only become available when their research thresholds are met. This test checks that the stats are high enough, as well as research values and that required buildings exist. This is a white box test since we need access to the data members that store buildings and research values. This will be a regression test that is used when we add new buildings as well as modify the requirements for existing buildings.

The purpose of this test is to ensure that State correct updates at the end of the turn based on the continuous Specs of its current Buildings. This reinforces the tests for Spec arithmetic, as well as ensures that the game logic will accurately compute changes to the player's progress at the end of each turn. The test will be crafted to the particular implementation to explore edge cases and hence will be a white box test. This will be a regression test that we will run as new States or building types are added, ensuring that the method works as it should under such changes and that the game logic is robust regardless of other implementation changes.

The purpose of this test is to ensure that the game data contained in Stats is properly displayed as a progress bar. Since this is all hand-coded using relative values to determine sizing of the rectangles representing the bars, the implementation is very risky and prone to bugs. Thus we will simulate multiple States and various changes to them and observe the results. Since the return value is simply a Window, the test must be done through the GUI and inspected for correctness.

The purpose of testing these similar methods is to ensure that the Stats returned have the correct values. These stats are the main component of tracking progress in the game, and ultimately determining if the player wins or loses. We will test this method by creating various Specs using boundary case values (like negative and floating point values) as stats and making sure that each of these are returned correctly. This is a black box, unit test because we are simply testing that the methods work as they should, without designing the tests around their implementation.

The purpose of testing these similar methods is to ensure that we can change the stats in a given Spec correctly. As before, these stats are the main means of tracking progress in the game. We will test this method by creating various Specs using boundary case values for the Stats and then changing them. We will also check to ensure that this method provides a deep copy and not a shallow one. Since the getStat() method would be tested before, we can call that method to make sure the Stats are correctly changed. Therefore, this will be a black box unit test because we will write the test knowing the interface but not the implementation.

Note that these correspond to two similar, but separate tests. The purpose of testing these methods is to make sure that we can add and subtract Specs throughout the game. This is integral of the game logic because at the end of every turn, these Specs are used to update the State of the game. It is a data structure that needs to work correctly for the rest of the game to function properly. We will test this by creating various Spec using boundary case values. We will then add and subtract the Specs and check to ensure we get the expected result. We also will look at adding or subtracting one Spec from itself to make sure that there are no problems in this regard. This will be a black box unit test since we know that we can add and subtract, but do not need to know the implementation to design the test. \end{description}

The purpose of this test is to ensure that SpecAnalysis properly determines recommendations based on the provided state. This functionality is used in making recommendations to the player as they progress throughout the game, and thus checking that the suggestions are made correctly is an effort to ensure the educational message is both as intended and complete. Moreover, this test is an additional test between the interaction between Spec and State, providing an alternative means of testing these classes.

The purpose of testing this is to ensure that the continuity of a scene is not distributed by going backwards to before the start of the scene and then resuming the scene. Furthermore, we want to ensure that the end of scenes lead to the correct next screen.

The purpose of testing this is to ensure that the player must progress through the tutorial by only clicking on appropriate buttons. We want to make sure that these buttons respond as they would in the game and that clicking on other buttons or keys, there is no response. This is a black box test unit test because the tutorial consists of other subclasses and we need to only visually ensure that nothing is being skipped or working incorrectly.

The purpose of testing this method is to ensure that the default response for the Window object is returned when appropriate. This will be a white box test because we will design the tests knowing the Window object first checks its components for a response and only returns the default response when there were no collisions. Since this function takes coordinates and returns a signal, we can write a component test that creates various Window objects and then computes responses for various input positions and then checks for the expected response.

The purpose of this second test for the same method is to ensure that Window and WindowEntry integrate as they should. The testing procedure will be similar to the first test of this method, but will be targeted at checking for correctly translating coordinates and correctly accessing data members of WindowEntry from in Window. As before, this will be a white box test since the tests will consider the order in which responses are determined. Lastly, this will be a regression test because modifications to these classes and elsewhere should not affect the process for determining responses, which is an essential element to the operation of the GUI. Thus we will want to this framework to consistently operate as it should.

As with the corresponding test for WindowEntry, this test will ensure that WindowEntry objects are rendered properly on top of each on a single surface. As this returns a visual result, we will have to test it by creating Windows with different WindowEntry objects and then observing that they render correctly. Since this is ultimately a test of our understanding of how PyGame renders on a surface, it will be a black box test, since the tests will not be specific to any method implementation.

The purpose of testing this method is to ensure that the continuous and initial Specs can be returned. Thus, this is an integration test because it relies on the Spec class. We will test this by creating Specs as in the Spec class tests and then making sure these same Specs are returned. We will also test changing the Specs using the Spec class, and then trying to get the Spec. This is a gray box unit test because we know that Specs are being used and that we can change these, but we do not know exactly how this method works.

The purpose of testing this method is to ensure that we can update Specs outside of the Spec class, by replacing the entire Spec. We will test this method by creating various Specs as in the Spec class tests and then changing these values. We will also test this by assigning one Spec to another and making sure each still updates and is displayed on their own. Since the getSpec() method will be tested before this, we can use it to make sure the Specs are correctly changed as it would be used in the rest of the program. Therefore, this is a gray box unit test as well as an integration test since we rely on the Spec class working correctly, and we do not know the exact implementation of the method.

The purpose of testing this method is to ensure that any given building can be added to the map. This is important because this is one of the main means of feedback and entertainment for the player. We will test this by adding buildings to the map, including the special cases when we add buildings that already exist as well as when we add those same buildings in different map Blocks. This is black box integration test as it tests the interface between Block and Map, but only using Map's interface to design the test.

The purpose of testing this method is to ensure that at the end of a turn, the map is updated with all the correct buildings that were made during one turn. We will test this by creating a list of buildings that will need to be updated in the map. To test some boundary cases, we will add multiples of the same buildings as well as add no buildings during a turn. Because we do not need to know how buildings are being added in these tests, this is a black box test.

The purpose of testing this method is to ensure that we can correctly detect when there is space to build a building. We will test this by asking to add buildings one at a time, including when there is no more room on a given screen. We will make sure that the buildings are only allowed to be added when there is space. Since we know what the max number of buildings on a screen is, this is a white box test. It is a unit test because the information depends only on this method and nothing else, while still being an integration test because it involves the interface between Map and Block.

The purpose of these tests is to check that the build menu properly transitions between menu pages when the next and previous arrows are clicked. We want to make sure that all pages are displayed and that the page order is correct. This is a gray box test because we want to make sure the pages advance correctly with the knowledge of the page size and the number of desired pages. This is an integration test since we are testing the interface between BuildMenu and MenuPage using the BuildMenu interface.

The purpose of testing this method is to ensure that the game can be updated at the end of every turn. This is extremely important because this method interfaces between several other classes in order to update every aspect of the game. Thus we will test this higher-level method correctly calls on the lower-level methods to end a turn in the correct order and that there are no unexpected side effects. We will test this method for turns that include multiple actions and no actions as boundary cases. Furthermore, one of the risks associated with this function is that it transfers data from one State to another. Since this changes critical information, we will want to ensure this function works properly and will design the test by examining how this operation is performed.

The purpose of testing the createWindow method is to ensure that the correct Windows are created when prompted. This is important because this information will be used by main to create a list of the current Windows, which are displayed in the UI class. Since we know that the list is split on the underscore character, we will test this method by giving it a sequence that involves many underscores in a row as well as sequences that have no underscores. This is a white box test because we know exactly how the information is being parsed. It is a component test because the parsing is the base of many other classes as well as this function encompasses one of the main jobs of the Game class.

The purpose of testing the build method is to ensure that the buildings the user decides to create are indeed being created, that there is space for the building to be created, and that the building actually can be created based on the current game progress. Because of this task, the build method calls upon other classes, such as Map and Turn, and therefore this will be an integration test. We will test that this method correctly calls the other classes' methods without side effects and that the overall response is that a new building is created, as desired. We will try edge cases, such as creating buildings when there is have no space in the current block, insufficient stats in the State, and building something has not yet been unlocked based on the game progress. This will be a black box test as we will examine Game's interface without looking at its implementation in order to test these situations.

The purpose of this test is to ensure that TurnMenu can properly interface with State, as well as Building, to correctly determine what can and cannot be built by the player at a given moment. This can be tested by passing the method a number of different States and compare the returned result with expected values of what is and isn't buildable. This is important because menu options change as the game proceeds and we want to ensure we will be able to correctly accommodate those changes. This will be a black box test because we will simply design the tests around the method interface, without examining the implementation.

The build menu is dynamically created and thus this function constructs the appropriate Window to return for a given State. A major concern is whether the Window will have overflow if there are a lot of things that are buildable. This will be a white box test, as it will examine the for loop that is used to create the menu and try to cause an overflow. It will also test the ability to retrieve the necessary information and image for the menu items during run time as soon as the menu is opened. Since the return result is a Window, we will have to evaluate the results of the test with the GUI.

The purpose of testing this method is to ensure the correctness of the technique to determine if a collision has occurred with a WindowEntry, which is essential for parsing graphic user interface input. However, because the parameters are just a position, we can test this method by constructing a WindowEntry with an assortment of different rectangles and images, and test the collision response for a number of coordinates. We will test boundary cases like negative coordinates, empty WindowEntry objects, etc. Thus it will be a simple unit test of this specific method and will be a white box because we will design the tests knowing the order in which the WindowEntry's individual components are tested for collisions. Furthermore, this is a regression test because we want to ensure this functionality remains intact as we develop elsewhere and possibly add to the contents of WindowEntry.

The purpose of testing this method is to ensure that elements of a WindowEntry are rendered properly onto a surface and in the correct order. Since the return type is a surface, the test requires visual inspection to verify correctness through the GUI. We will construct WindowEntry objects with an assortment of overlapping components, added in different orders, and verify how they are rendered. This will be a white box test because we will design the tests cognizant of the order in which a WindowEntry's components are rendered to the surface. Furthermore, this is a regression test since this is how all visuals are rendered and we want to ensure this remains correct throughout development.

The purpose of testing this method is to ensure that the user interface is working correctly and can recognize the user's mouse clicks. We need to make sure that the clicks that are recognized have the same responses that the user expects. If this method does not work correctly, the game will not function properly and the user will become frustrated, which will decrease the learning opportunities. Knowing this, we plan on testing this method by clicking along the boundaries of buttons to make sure that no clicks are wrongly interpreted. We will also make sure that each button has the proper response when clicked on. Because this method is the primary means of interfacing with the user, this will be a regression test used throughout any GUI test. Since the results will be visual, this is a black box test that will be done using GUI.

We propose unit tests for WindowEntry, Spec, and Map \& Block. These are the primary low-level classes and retain actual game data. Thus by testing all of these with unit tests, we ensure the foundation of our program and provide a framework to extend beyond these classes in testing higher level classes, some of which must interface with these classes. Therefore these unit tests would allow us to proceed in checking more complicated classes and methods, knowing the simple components work as they should.\\\\

We propose component tests for WindowEntry, Window, TurnMenu, State and Game. All of these classes contain several methods that must be tested in tandem in order to fully test the class. Moreover, these classes all retain game data and component tests will ensure that the data is handled and manipulated properly through the various methods that they perform. Ensuring the accuracy of the internal game data is an essential requirement that will be addressed by these component tests.\\\\

We propose integration tests for Window, TurnMenu, State, Game and UI. These are the primary classes that have to work intimately with the other classes. In particular, all of these classes must interface with each other at some level. Thus we intentionally build in some redundancy in our testing by designing tests that target the interfacing performed in each of these classes. Moreover, the other classes not included here, like WindowEntry and Spec, do not access data from other classes, but instead are low-level. Thus integration tests for these classes that manage and interact with various other classes should be sufficient and thorough.\\\\

We propose system tests for UI and the entire program via main.py. A system test for our program would necessarily entail testing all the components by playing the game. We will use the game, paying attention both to the correctness of the UI responding to input and the general correctness of game logic and displays. By intentionally playing the game by looking for edge cases, focusing on new features and playing often, we will expose bugs that are apparent to the player, which are the types of bugs that must be infrequent as possible. Essentially, by experiencing the program as any user would, we will ensure that the game functions cohesively and as it should, testing the complete framework of the system.\\\\

Regression tests are proposed for WindowEntry, Window, State, and UI. The reason for testing these classes with regression tests is that these are the core classes that retain game data and dictate the program behavior. Thus as we add features and extend the program, these classes should retain entirely functional and unaffected. In other words, these are the classes that should work independently of changes elsewhere and should scale as the project and game does. Moreover, an error in these classes would cause an error in most other classes. Thus by using regression tests on these classes, we will isolate any bugs that do exist more effectively.\\\\

We propose both white and black box testing throughout. Any tests that require visual results to confirm the correctness of classes or methods was cast as a black box test since it will be handled through the GUI, which doesn't allow insight into the implementation. Moreover, simple methods that do not contain particularly complicated implementations can be tested via black box tests by only looking at the class interface. These tests simply ensure that the desired results are provided for particular methods and don't try to break a messy implementation. White box tests, however, address methods that are more complicated and contain more control statements. These tests were proposed for any methods with tricky implementations and for methods where the ordering of certain operations matters (like in what order things are rendered or checked for collisions). Moreover, white box tests were proposed for things that seem susceptible of working improperly (like TurnMenu that dynamically builds the menu with the chance for overflow).\\\\

We deem our test coverage thorough. We have proposed tests for all non-trivial classes in our program and for each nontrivial method. Moreover, various integration tests will test the same classes and methods multiple times. Thus each relatively risky class is addressed with tests both focusing on that class and via integration tests, as well as indirectly through system tests. This threefold approach to testing each essential to the game will ensure the coverage has both depth and breadth.\\\\

Some shortcomings of our test plan include a heavy reliance on GUI tests. These tests are cumbersome, require a user to walk through and do not provide clear, quantitative results. However, since this will be how the user experiences the program, it is important that we test from this perspective. Another shortcoming of our proposed tests is that Block and Map are tested together and thus a bug would require first determining in which class the problem is in. However, the reason for this coupling is that the classes work intimately together and the tests would be too contrived and unhelpful to test these classes in isolation. Lastly, our test plans offered no system test that doesn't use the GUI. It was not clear how a test that did not require the GUI could be designed since in order to test the entire framework, since we rely on graphical user input for game events to occur. Nevertheless, it would be preferred if we could run an automated test that would check essential operations in the system as a baseline for the program's correctness.