Sprint 1 Testing

All additions to the base game during sprint one had to be tested to ensure correct functionality and safety of the game build. This included automated testing wherever possible however due to current limitations in knowledge a high amount of testing was done functionally.

Automated Testing

Wherever possible the added player functions were tested utilising Junit tests as this ensured the functionality would be verified and maintained for every build of the game. This mainly applied to the player's combat statistics, which was mainly setting and providing statistics to be used in other methods, allowing easy access to variables for testing (seen here). The other major component tested in this way was the movement state changes and some of the triggers for dash, as getter methods were included to ensure other systems within the game would have access to the states of the players movement later in development (seen here).

Functional Testing

In this part of the sprint many methods of automated testing were unavailable, including mocking, therefore a high proportion of tests would need to be functional. This mainly included functions to do with attacking and dashing which where dependent on entity locations, interactions and events.

The majority of the attack testing was done by monitoring logger output due to lack of visual feedback this early in development. Each enemy hit was observed and monitored and compared to the expected output.

Dashing

In Player Actions the players directions for dashing couldn’t be tested as the variable for movement speed alteration (desiredVelocity) is only within a private function and only used in the instance, therefore it would be bad practice to make a public getter and maintain an instance to test it (as it wouldn’t be used for any other purpose).

Testing Method: User holds "W" and presses "Shift", they should see the player character move quickly in that direction. This should be repeated for horizontal, vertical and diagonal directions, all of which should be even.

In KeyboardPlayerInputComponent disabling the ability to attack during dash was unable to be tested as the method stops the attacking events from being triggered and there are no methods to return whether the player is currently attacking, which at this current position in the sprint would be the only method to test.

Testing Method: User presses "Space" during dash, no melee attack sound should occur. User then presses “Enter” during dash, no ranged attack should spawn.

Melee Attack

Currently, melee attack involves player inflicting damage on the enemy if and when the enemy is close enough for damage to be dealt (not dealing any damage if the enemy is out of range). This involves multiple entities working cohesively and therefore requires being able to monitor interactions/collisions for automated testing to be done, which was not yet possible in the current sprint.

Testing Method: User presses space when enemy is not within range, no damage is dealt to enemy but melee sound should be heard. If the enemy is close enough, damage would be dealt when space is clicked after the enemy enters the attacking range.

Long Range Attack

Bullets are entities that will be spawned when the game is loaded. A bullet is then shot (moved) from the player's position (possibly anywhere in the game area), and will travel towards the end of the game screen's boundary. Bullet will need to be able to collide with NPC/obstacles/game boundaries and be disposed of if it does collide with these entities in the game. Similar to melee attack, many entities are interconnected and it needs to travel with time in game and track any collisions which makes it unable to test currently.

Testing Method: After starting the game, if "Enter" is pressed a projectile will be shot from the player in that direction, moving until it collides with an object and disappears. This should be repeated for all 4 main axis directions. If the projectile it collides with an enemy it will also deal damage.

User testing

See the user testing document

Future Testing

In future sprints, due to more knowledge on testing measures such as mocking, more automated testing will be included. Additionally as more assets and feedback measurements will be present the game, more user testing directly related to the functionality and balancing will be possible.

Automated Testing

In future sprints we will have access to more testing methods for functionality which relies on movements and interactions, therefore many of the functional tests present in sprint one will be modified as much as possible into junit testing to ensure that these features are properly verified on every build of the game.

• Converting functional testing into automated testing wherever possible.
• Improving current junit tests/adding more to increase coverage now that other components have been merged.

Functional Testing

Though it is not preferable functional testing is an important aspect for bug testing and verifying the player experience occurs as intended. Therefore the current functional tests may still be verified semi-often (often when manipulating code interacting with these exact functions), as well as added functional testing to accommodate other teams code

• Adding functional tests till accommodate changes and possible issues of interaction between different teams work moving into the next sprint
• Maintaining aspects of some current functional tests as means of verifying bug testing

User Testing

As more components are added user testing becomes far more important to ensure a cohesive user experience. Additionally, as more feedback mechanisms are added it becomes more straight forward to test the functional features which can only be understood through these additions.

• Repeating the current user testing method with added assets and feedback measures.
• Constructing a new user test(s) to focus on balancing the player with the game world (especially enemies now that they are present in the game).
• User testing on the designs which wasn't able to be completed during the first sprint, to ensure any issues are found early
• User testing concerning the designs within the game world, to ensure a coherent experience across assets created within the sprint.