Team 1 Testing Plan Sprint 2

Introduction

Team 1 was tasked with the creation of buffs and de-buff status effects. When the player collides with these status effects the player's stats will change temporarily (in response to the type of status effect). For example, a speedBoost status effect 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, JUnittests were implemented to validate the chain of method calls and return values. The class that was tested was the StatusEffectOperation.

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 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 highlighted in the Mocking section. The same reason applies to .getComponent(CombatStatsComponent.class).

Overwriting Functions

As a direct result of mocking classes 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 the StatusEffectOperation class were the focus of testing.

Methodology

Buffs and de-buffs have two states of termination, asynchronous termination through its duration time and, through player death. These tests were split into two JUnit tests, however, they are largely the same. To demonstrate the methodology, the code for testing speedBuff when the player is not dead will be explored. 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 = 10f;
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 = 5f;
float result = speedBoost.speedChange(type); // This changes the speed stat of the player by the amount of the `speedBuff`. .speedChange() returns the difference between the new speed and the original speed. 

Lastly, the player's stat is appraised to check that the speedBuff has altered the player's speed.

float expected = 15f;
float result;
assertEquals(expected, result);