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, JUnit tests were implemented to validate the chain of method calls and return values. The class that was tested was the StatusEffectTargetComponent.

StatusEffectTest

Mocking

Mocking was used to remedy issues that arose due to the high coupling between StatusEffectTargetComponent with the Entity, ServiceLocator, GameTime, and PlayerActionsclasses. One of these issues is highlighted below, where the method call for theEntityobject,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 componentStatsComponent combatStatsComponent = new private CombatStatsComponent(1, 0);

@Test
public void testSpeedBuffIsDead() {
when(player.getComponent(PlayerActions.class)).thenReturn(playerActions);
when(player.getComponent(CombatStatsComponent.class)).thenReturn(combatStatsComponent); // 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).

JUnit Tests

JUnit tests were written for each of the implemented buff and de-buffs. These were SpeedBuff, SpeedDebuff, JumpBuff, TimeStop and StuckInTheMud. Confirming the change in stat and code behaviour were the focus of testing.

Methodology

The lifecycle of a status effect can be broken down into three distinct stages: acquisition, application and removal. The acquisition stage is the process of acquiring the status effect, which is stored in a private member variable. This is facilitated by the function applyStatusEffect(). Tests were written to confirm that the correct status effects were being stored.

StatusEffectTargetComponent SETC = new StatusEffectTargetComponent;
/* apply speed boost */
SETC.applyStatusEffect(StatusEffect.FAST);
assertEquals(StatusEffect.FAST, SETC.getCurrentStatusEffect());

More importantly however, applyStatusEffect() prepares the application stage by performing operations to determine the magnitude of the stat change. This behaviour was tested using verify() to ensure that the expected number of calculations were being called.

/* We expect the getComponent(PlayerActions.class) is called twice when applying the speed boost */
verify(player, times(2)).getComponent(PlayerActions.class);

Next, the application stage was tested. Application requires changing the stat of the player in accordance to the current status effect. Using the mocked Entity class (player) to return an instance of a PlayerActions class (playerActions), the stat of the player entity can be altered and compared to an expected value.

/* apply speed boost */
SETC.applyStatusEffect(StatusEffect.FAST);
float expected = 15f;
float result = playerActions.getSpeed();
assertEquals(expected, result);

Lastly, the removal stage can occur in two separate occasions. The first situation occurs when the current status effect is still in effect and a new status effect is acquired, replacing the former status effect with the newly acquired one. The second situation occurs when the duration of the current status effect has elapsed, and is thus promptly removed from the player. The first situation occurs automatically when applyStatusEffect() is called whilst the second scenario occurs when the update() is called.

/* apply speed boost */
SETC.applyStatusEffect(StatusEffect.FAST);

/* apply jump boost */
SETC.applyStatusEffect(StatusEffect.JUMP);

/* the speed boost should be replaced by jump boost */
assertEquals(StatusEffect.JUMP, SETC.getCurrentStatusEffect());

/* remove jump boost as its duration has elapsed */
SETC.update();

/* current status effect should be null */
assertEquals(null, SETC.getCurrentStatusEffect());

Additionally, the behaviour of the removal process is also tested. The removal process does the same operation that applyStatusEffect() uses in preparation of application stage and thus, the process of applying a status effect and removal requires calling the same function (player.getComponents(PlayerActions.class)) between 2 to 3 times. Similarly, the stat of the player is tested to ensure that the stat buff/de-buff has been correctly removed.

/* apply speed boost */
SETC.applyStatusEffect(StatusEffect.FAST); // player.getComponent(PlayerActions) is called 2 times
SETC.update(); // player.getComponent(PlayerActions) is called 1 time
verify(player, times(3)).getComponent(PlayerActions);

/* assert to determine if the player's stat has returned to normal */
float expected = 10f;
float result = playerActions.getSpeed();
assertEquals(expected, result);