General Mobs Testing Plan
To test each task of the General Mobs feature, a mix of JUnit tests and other tests during gameplay have been implemented.
As this acts as a container the only JUnit testing written was the initialisation of the class and the idGeneration. This was done by ensuring no exceptions were thrown, and the toString matches the expected entity created. Tests for this were written under EnemyTest.
@Test
void idGeneration() {
BaseEnemyConfig enemy1 = new BaseEnemyConfig(drops, closeRange, longRange);
BaseEnemyConfig enemy2 = new BaseEnemyConfig(drops, closeRange, longRange);
assertNotEquals(enemy1.getId(), enemy2.getId());
assertEquals(enemy1.getId() + 1, enemy2.getId());
}These are base implementations and do not have functionality, and therefore only initialisations is required to test for. This was done by hand by implementing Melee and Weapon in PredefinedWeapons. Predefined weapons are used on the Xeno enemy and were tested at runtime by adding some of the attributes to close and long-range abilities of the enemies. For further development, tests for these should be implemented.
There were two JUnit tests made to test that the random function worked, ensuring that random long range and close range were selected if more than one was viable.
@Test
void shouldBeRandom() {
CombatStatsComponent combat = new CombatStatsComponent(100, 20);
ArrayList<Integer> possible = new ArrayList<>(Arrays.asList(1, 2, 3, 4, 5));
ArrayList<Integer> dropped = new ArrayList<>();
for (int i = 0; i < 20; i++) {
dropped.add(combat.pickRandom(possible));
}
assertFalse(Arrays.stream(dropped.toArray()).allMatch(t -> t == dropped.get(0)));
}The other test implemented was to check that the state correctly changes based on the current health of the entity. Other testing for the weapon selection was done during runtime. This was conducted in hand with TouchAttackComponent that would correctly select a long range if there were no close range, and that objects were randomly selected. Writing the tests for these is possible however, complex and was avoided and tested by hand.
To check the implementation of the selection of weapons and applying the correct damage, the change in health before and after attack was measured. All ghosts were initialised with abilities and the player would move to the target while the game is running, and the printed stats were checked.
Once the assets had been chosen, the existing ghost sprites were replaced with the new ones. The game was run with the new assets and all of the ghosts had become Xeno Grunts. From here, the testing was done by inspection.
If a visual issue was observed in the game loop, elements were changed in the asset folder until the issue was no longer present. Once familiar enough with how the assets were read, a new entity was made similar to the existing ghost entity. Testing for this new entity was also done by inspection, as the testing suite was not clear on how assets and animations should be tested. Initially it was found that the entity size was too large. Different values were changed in the .atlas file corresponding to the sprite coordinates, and it was found that by making the size of the sprites larger, the entity would be rendered smaller.
Elements of the XenoAnimationController and ForestGameArea class were also changed to accommodate the new entity. Additions made here were initially very similar to the ghost entity, however more changes would be made later down the line. These changes included integration of other contributions made by the rest of the team, such as BaseEnemyConfig. The additions here were tested by inspection too, mostly using prints to the command line to verify expected behaviour.
As the projectile shooting has not yet been incorporated with the mob entities, a print statement has been included which occurs whenever the ShootTask is initiated. This task prints to the terminal and is initiated in the start() function of the class.
@Override
public void start() {
super.start();
System.out.println(this.message);
}During gameplay, if the window is minimised and not on full-screen mode, these print statements can be seen whenever the player moves within range of the Xeno Mob Entity. In future work, the projectiles will be implemented with this class so that the mob shoots projectiles at a specified target. The expected print message is given below, where target is the Entity moving within range of the mob (in this case, the player).
this.message = "Shoot Task Activated " + target;When attempting to test the movement, since the getDirection() function was a private helper function, it was unable to be called and tested within a JUnit test. Consequently, the functionality of mob movement was verified visually.
As seen, the mobs move in a straight line toward the left side of the map. This matches the expected functionality of the WanderTask, where the target position is set by the getDirection() helper function.
Again, since the spawning of mobs was implemented within a private method, testing the spawning locations using JUnit testing did not seem to be plausible. Consequently, the functionality of randomly selecting a world tile to spawn in was verified by a simple print statement to standard output. There was an associated print statement for each mob which showed its spawning coordinates. When this print statement was executed, it could be confirmed that the Xeno mob was successfully spawning on the map.