Sprint 2 Testing

For testing in sprint two the majority of effort was placed into increasing the Junit testing from the functions implemented in the previous sprint and including more user testing due to the high increase in features. Overall many of the testing goals from sprint 1 were achieved within sprint two, however certain aspects needed to be further pushed back due to current circumstances.

Automated Testing

For the main untested components from the previous sprint (namely ranged attack, melee attack, dashing) unit testing was able to be added to increase coverage to a significant degree for these components/functions in order to ensure the functionality. Additionally most added components were tested through Junit additionally.

Functional Testing

Very little functional testing was required for this sprint, however certain components related to animation and visual presentations still required testing to be done manually.

PlayerInterfaceDisplay

On the player's HUD interface, there are 3 main things that will continuously be displayed and updated throughout the game. Firstly, the health interface animation which is updated based on the currently health and wound state of player (which gets updated when player heals or receives damage). Next, the dash cooldown bar (this empties when player presses SHIFT and it start to refill to the fullest to indicate to player when it is time for player to be able to dash once again) and lastly, the items which includes ammo, coins and bandages (these are updated when items are picked up or used - whether it may be bandages to heal wound state or ammo to reload gun magazine). Although there are unit tests in placed to test the behaviour of how each method should act when a variable is passed through - there is no way to check if it is being displayed properly on screen. Hence, the best way to test is functional testing as explained below.

Testing Method: When user receives damage, the health bar interface will begin to empty out (colourless) and when player is about to die the health bar will change its colour filling. If a bandage is used, a wound state is restored and the health bar should be filled with a colours that corresponds to player's current wound state. Next, clicking SHIFT would empty dash bar cooldown and it should continuously fill up to the fullest again and if player decides the dash again - the action would be execute and the process would repeat all over again. Finally, any items used or picked up will be seen to be updated - whether it may be via picking up or using them (reloading by pressing R to fill up gun magazine or pressing 1 to use bandage to heal).

PlayerAction - Reloading check

This is an action that is triggered by pressing the R key. It essentially has a delay to it (2 seconds) and it then reloads the gun magazine of player to the fullest. It will not trigger when there is no ammo in player's inventory or when gun magazine is already full. This was tested initially and it was passing locally. However, it fails when the test is pushed to Github. This will however, be revamped and improved for the next sprint. Currently, the best way to test the functionality of such implementation is via functional testing.

Testing Method: When user presses R with gun magazine being full, nothing will happen or if when there is no ammo in inventory. However, when there is ammo and gun magazine is not full (5 is the max) and user presses R, a popup label will be shown at the bottom center of the screen. This text will indicate that player is currently reloading the gun and once the text disappears, the gun would have been successfully loaded and player will then be able to shoot as usual in game.

User Testing

In order to ensure good coverage through user testing three separate testing documents were created and acted upon. These allowed us to test the designs from our previous sprint (including those from another team) as well as the main items addition. These user testing documents included: Player & Item Designs, Hud Designs, Item Functionality (explanations all included in the wiki documents).

Future Testing

In future sprints, due to more polishing and additions to the game, user testing and integrated testing will become a higher priority as the game builds and becomes more advanced/complexed. Due to this there will be more importance/priority will be given to these aspects. Additionally, due to late pushes for other teams components integration testing/user testing across teams will also be important.

Automated Testing

• Improving current Junit tests/adding more to increase coverage now that other components have been merged.
• Adding more Junit testing, specifically for integration

Functional Testing

• Maintaining aspects of some current functional tests as means of verifying bug testing (specifically the display which is only verifiably tested by eye)
• Possibly including more unit testing for integration, depending on how integration testing goes in the later sprints

User Testing

• User testing revolving around the designs as a unit (across teams) to ensure the cross-team aesthetic has been maintained
• User testing in response to changes made to current designs in response to user feedback
• (top priority) User testing around combat balancing now that the base enemy modifications should be complete (likely to be done in collaboration between enemy and player teams)