Black Box Unit Testing

Black Box

These are boundary conditions organized by class. They are black box because they only depend on our actual classes and what is actually supposed to happen with our code. These are all individually parsed and have corresponding test cases enumerated on our issues tab.

Class GameController Boundary Conditions:

• The string "name" has a length that is too long to display properly. The system should not overflow displaying, instead should have ellipsis
• The player has no money left in their wallet. The game should not continue, instead the player should be prompted that the game is over and to submit their score
• The player name has the exact same value as another player. The system should have some way to differentiate these two users, so that a player can see all of their personal scores.
• The player wants to start a phase, or do something contextual to a phase (buy, sell, hunt) while not currently in that phase. The system should reject the call, and log it.

Class InvestPhase Boundary Conditions:

• The player wants to buy stock but does not have any money. The system should not change the player's stock count or deduct money for their wallet, instead give some visual stimulus to the user about how their purchase failed
• The player wants to sell stock but has no stock. The system should alert the player that the sale failed, and not modify their wallet.
• The player wants to buy or sell stock before the round has started.
• The player wants to buy or sell stock after the round has ended.

We expanded these boundary conditions into test cases, which can be found here.

All of our tests ran successfully on our first implementation code, however, Mridul pointed out he felt we did not have enough tests. He thought we should have tested buy and selling multiple stocks, not just one. Additionally, we should have tested buying and selling stocks mid-round, as opposed to at the beginning of the round right after we add a new point. I feel this makes a lot of sense, and for the next testing assignment we plan to include this. Another point that would have been good to test would be if we rapidly tried to buy and sell stocks faster than they were being generated for the entire length of the first round. We should have done this two ways. The first way would have been by calling buyStock and sellStock, repeatedly, and the second way would have been by rapidly having our UI elements automatically pressed; the second way would have been helpful to test because since our game is front-end heavy, we want to test our UI elements. Additionally, we did not include the leaderboard for this iteration, but, in the future, many tests can be done involving it. Such as posting to the leaderboard multiple times with the same name and tampering; we want to make sure our data store reacts consistently.

We also had a small issue concerning our socket connection. We had to make a modification to our front end socket connect call in order for the game to connect between computers, from 'localhost:8000/' to simply '/'.

Additionally, we added some tests under issues (in addition to our closed/completed ones), that we thought of off the top of our heads; these will be further fleshed out during the next implementation and testing.

Tests were also added as succinct cards to our Trello, so that we could easily keep track of them.