Changeset 316

03/27/2012 04:31:35 AM (3 years ago)

fixed dead link

2 edited


  • design/testing/test_plans.tex

    r315 r316  
    152  \item[\hypt{state:build}{addBuilding(building)}] -- White Box, Integration, Regression Test \hfill\\
     152 \item[\hypt{state:build}{addBuilding(building), deleteBuilding(building)}] -- White Box, Integration, Regression Test \hfill\\
    153153 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.
    154154  \item[\hypt{state:research}{research(category, value)}] -- White Box, Integration, Regression Test \hfill\\
    170170  \item[\hypt{spec:set}{setMoney(newMoney), setPower(newPower), setMaterial(newMaterial)},]\hfill\\\textbf{setSpace(newSpace), setPollution(newPollution)} -- Black Box, Unit Test\hfill\\
    171171 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.
    172  \item[\hypt{spec:add}{\_\_isub\_\_(otherSpec), \_\_iadd\_\_(otherSpec)}]-- Black Box, Unit Test\hfill \\
     172 \item[\hypt{spec:add}{\_\_isub\_\_(otherSpec)}, \hypt{spec:sub}{\_\_iadd\_\_(otherSpec)}]-- Black Box, Unit Test\hfill \\
    173173 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}
Note: See TracChangeset for help on using the changeset viewer.