Team 4 Testing Plan Sprint 2

Unit Testing

LevelGameAreaTest

There are multiple unit tests to provide coverage for the LevelGameArea mapInteractables() function. beforeEach registers the physics service before each test is run to avoid running into any NullPointerException. It also clears the class variables obstacleEntities and mapInteractables to ensure no two tests interfere with each other.

onlyInteractables creates six ObstacleEntity: three buttons, two doors, and one bridge. This is the case in which there are no entities that do not have an InteractableComponent or SubInteractableComponent, and thus the expected case is that all entities are added and mapped. It also creates two new local variables, newObstacleEntities which directly adds each entity to the list and newMapInteractables which directly maps each interactable entity to each sub-interactable entity in order of creation. Then, it calls mapInteractables() and compares newObstacleEntities to this.obstacleEntities and newMapInteractables to this.MapInteractables.

notOnlyInteractables creates ten ObstacleEntity: four platforms, three buttons, two doors, and one bridge. This is the case in which there are four entities that do not have an InteractableComponent or SubInteractableComponent (the platforms), and thus the expected case is that not all entities are added and mapped. It also creates two new local variables, newObstacleEntities which directly adds each entity to the list and newMapInteractables which directly maps each interactable entity to each sub-interactable entity in order of creation. Then, it calls mapInteractables() and compares newObstacleEntities to this.obstacleEntities and newMapInteractables to this.MapInteractables. In this case, it is expected that all four platforms are left out of the newMapInteractables and subsequently this.MapInteractables, even though they are added to newObstacleEntities and this.obstacleEntities.``

PlayerMovementComponentTest

This test class has been extended from sprint one to text the extended behaviour of the PlayerMovementComponent class. Two new test methods have been written, both of which are currently commented out. These tests are commented out as it seems it will be easier, at least most definitely possible, to test this extended behaviour as user testing. Currently it is believed that the ColliderComponents of the mapped sub-interactable entities cannot be create() and dispose() properly under JUnit test conditions. More will be developed on this in sprint three after maps integrating the interactable elements are readily available to be tested with. Here, doors refer to portal elements.

There are multiple unit tests to provide coverage for the PlayerMovementComponent class. beforeEach registers the physics and resource services before each test is run to avoid running into any NullPointerException. It also clears the class variables mapInteractables to ensure no two tests interfere with each other.

opensDoor creates two ObstacleEntity (button and door) and one Entity (player). It adds the button - door mapping to mapInteractables. Then, it retrieves the player's fixture and button's fixture, and triggers the onCollisionStart function on the two fixtures. Finally, it checks whether the mapped door's HitboxComponent and ColliderComponent have been disposed of. Doors are intended to be created with colliders to enable collisions with the player.

extendsBridge creates two ObstacleEntity (button and bridge) and one Entity (player). It adds the button - bridge mapping to mapInteractables. Then, it retrieves the player's fixture and button's fixture, and triggers the onCollisionStart function on the two fixtures. Finally, it checks whether the mapped bridges's HitboxComponent and ColliderComponent have been created. Bridges are intended to be created without colliders to disable collisions with the player.

User Testing

Interactables Animations & Design

User Testing for this section was completed on the design and animations of the (currently) planned interactable entities in Runtime. These include the Jump-pad, the floor button, and the portal. This test was a 3 participant interview using the Think Aloud method. Participants were shown the assets' design and animation, as well as the general aesthetic of the game and then were asked the following 5 questions each:

1. What are your first impressions of the assets?
2. Do the designs fit with the broader visual themes of the game?
3. Does the mood given off by the assets suit the style of the game? (You being a virus infiltrating a computer)
4. Do you agree with the colour schemes and general aesthetic in context of the other assets in the game so far (menu screen, buttons, music, etc.)
5. What recommendations do you have for the design and/or animations of these assets?

These questions were all answered with each participant speaking their thoughts aloud when they came to them. The results of these are presented here.

In future, when these assets are all implemented and working within Runtime, it would be beneficial to run this user testing again with a focus on functionality, timing, flow, and general feel of the animations/designs. Specifically focusing on the fluidity of their use within multiple levels would provide a greater understanding of potential improvements.

Level Design Prototypes

In order to determine the usability and difficulty of the map design for Level 2 and Level 3 (currently), a Think Aloud User Test was conducted. In this test, there were 3 participants who were shown both the sketched designs and implemented design in the game. To find any major flaws and possible suggestions to improve the current designs, they were then asked the following 4 questions:

1. Were there any major issues you had with the map design for levels 2 and 3?
2. Between Level 2 and 3, do you think the difference in difficulty was obvious?
3. Do you have any suggestions to improve the map designs for these levels?
4. What other interactable elements would you like to see in the next Sprint?

These questions were all answered with each participant speaking their thoughts aloud when they came to them. The results of these are presented here.

Future user tests should be conducted where the interactable elements are implemented in the game to find other potential issues with the map design for levels 2 and 3. In this user test, participants were only shown the sketched and implemented design, however it would be beneficial to ask the participants to play the game with the level 2 and 3 map to gain further understanding of the usability.