Team 1 Testing Plan Sprint 2

Introduction

Team 1 was tasked with the creation buffs and de-buff items. When the player comes into contact with these items the player stats will change temporarily in response to the type of item. For example, a speedBoost item will increase the player's speed stat by a constant amount and will last a predetermined duration before the player's speed stat returns to normal. In order to effectively test these operations, JUnit tests will be used to validate the chain of method calls and return values. The class that was test was the StatusEffectOperation class.

StatusEffectTest

Mocking

Mocking was used to remedy issues that arose due to the high coupling between StatusEffectOperation with the Entity and PlayerActions class. One of these issues is highlighted below, where the method call for the Entity object, player, returns null.

Entity player = new Entity();
player.getComponent(PlayerActions.class); // returns null
player.getComponent(PlayerActions.class).getSpeed(); // evaluates as null.getSpeed()

As can be seen above, the Entity object wants to call its respective PlayerActions component, however, the class is not instantiated and thus, the process of retrieving the player's speed is unreachable through calling the methods natively. To rectify this, the player is mocked to allow the tester to redefine the method calls for a testing environment.

Entity player = Mockito.mock(Entity.class)

Method calls can be redefined using the following syntax:

when(CLASS.FUNCTION(PARAMETERS)).thenReturns(RETURN_VALUE)

Using the above syntax, the following functions for the player object is defined:

private PlayerActions playerActions = new PlayerActions();
private omponentStatsComponent combatStatsComponentNotDead = new private CombatStatsComponent(1, 0);
private ComponentStatsComponent combatStatsComponentIsDead = new CombatStatsComponent(0, 0);

@Test
public void testSpeedBuffIsDead() {
when(player.getComponent(PlayerActions.class)).thenReturn(playerActions);
when(player.getComponent(CombatStatsComponent.class)).thenReturn(combatStatsComponentNotDead); // alternatively, return combatStatsComponentIsDead

/* test code */
} 

The above definition returns the PlayerActions object, playerActions, to the player whenever .getComponent(PlayerActions.class) is called. As such, this will not result in the null issue highlight previously. The same reason applies to .getComponent(CombatStatsComponent.class).

Overwriting Functions

As a direct result of mocking class and redefining the behaviour of their methods, the methods in StatusEffectOperation objects must also be changed in order to reflect this. Largely, this means removing code that is not relevant to the test; such as triggering events, private method calls and, explicitly link the player with its PlayerActions and CombatStatsComponent objects. When overwriting the function, care has been made in order to reflect the native call order of each function. The general syntax can be seen below for speedChange():

StatusEffectOperation speedBoost = new StatusEffectOperation() {
@Override
public int speedChange() {/* overwritten code */}

};

JUnit Tests

JUnit tests were written for each of the implemented buff and de-buffs. These were, at the time of writing, SpeedBuff, SpeedDebuff, JumpBuff and StuckInTheMud. The corresponding methods for the stat alteration in StatusEffectOperation were the focus of testing.

SpeedBuff/SpeedDebuff

Buffs and de-buffs have two states of termination, asynchronous termination through its duration time and, through player death. These tests are split into two JUnit tests, however, they are largely the same. The first test is to test the speedBuff if the player is not dead. In such a case, we first test if the player's current speed, prior to the speedBuff, is as expected. This is done through multiple assertion tests as follows:

float expected = 10;
float result =  player.getComponent(PlayerActions.class).getSpeed();
assertEquals(expected, result);
assertTrue(result == expected);
assertFalse(result != expected);
assertNotEquals(expected + 1, result);

Subsequently, the method to add the speedBuff is called. The change in stat is recorded and compared to the expected value.

type = 1;
float expected = 5;
float result = speedBoost.speedChange(type); // This changes the speed stat of the player by the amount of the speed buff. .speedChange() returns the difference between the new speed and the original speed.