JUNIT Testing and Code Coverage

Back to Combat Items Contents Page

Introduction

Testing is an important part of implementing any code whether it be into any software system. Testing aims to reduce bugs and poorly written code and ensures the functionality works. It is important also to consider input handling and how the code manages inputs which might not be expected without crashing the software. Hence, testing is an extremely important part of developing our game and polishing the game for the final sprint.

Code Coverage

Prior to sprint 4, we had only three classes with 100% code coverage and the remainder of our classes had either partial or no code coverage. While we did not achieve 100% code coverage on Sonarcloud all code added to the project was tested either through JUNIT, mocking or our visual testing plan.

Before Sprint 4

The following table shows the code coverage we had prior to sprint 4.

Class	Code Coverage
AnimatedImage	0%
AreaIfEffectStatsComponent	100%
AuraPickupComponent	0%
BuffDisplayComponent	0%
PhysicalWeaponStatsComponent	80%
WeaponArrowProjectileComponent	0%
WeaponAuraComponent	96%
WeaponAuraManager	0%
WeaponStatsComponent	94%
PlayerTouchAttackComponent	22%
PlayerCombatAnimationController	37%
CombatStatsComponent	48.7%
AuraConfig	0%
BaseAuraConfig	0%
WeaponConfig	100%
WeaponConfigSetup	100%
WeaponFactory	11%

After Sprint 4

The following table indicates the progress we made in implementing code coverage. Some tests however were not covered by code tests, but by a visual testing plan we created to ensure animations were running smoothly according to player actions. I've highlighted those with major changes made.

Class	Code Coverage
AnimatedImage	0%
AreaIfEffectStatsComponent	100%
AuraPickupComponent	6%
BuffDisplayComponent	0%
PhysicalWeaponStatsComponent	100%
WeaponArrowProjectileComponent	0%
WeaponAuraComponent	100%
WeaponAuraManager	21.4%
WeaponStatsComponent	100%
PlayerTouchAttackComponent	22%
PlayerCombatAnimationController	98.8%
CombatStatsComponent (updated our contribution to this class)	48.7%
AuraConfig	100%
BaseAuraConfig	100%
WeaponConfig	100%
WeaponConfigSetup	100%
WeaponFactory	47.8%

JUNIT Tests

The following sections outline what was and wasn't tested in a given class and provides a justification as to why this wasn't completed. This section is specific to those that do not have 100% or close to 100% code coverage.

PlayerTouchAttackComponent

For the PlayerTouchAttackComponent this was partially tested. In the final revisiting of code smells for this class, we made the decision to re-structure the attackEnemy() function to fix critical code smells. Unfortunately due to the time this took there was not sufficient time to improve test coverage given that there are various components which extend libgdx.

AuraPickupComponent

For the AuraPickupComponent while writing the tests for this particular class I encountered issues with passing through the game area specifically for the pickUpAura(). Despite attempting to mock this the test continued to fail. In future directions, this class should be revisited again and perhaps adjusted for more efficient testing.

WeaponAuraManager

The WeaponAuraManager was partially tested for all getter and setter methods. Initially all the getter and setter methods for changing variable components such as the weapon stats and name of aura we implemented with the single function ApplyAura(). I changed this so that those getter and setter methods were separated from the single method (which also changes animations) to ensure cleaner code and was more efficient for testing purposes. The checkEffectAura() was a method which was not checked as this relies on the time within to check the game has progressed so far into the future before disposing of an aura on a weapon.

Testing Plan for Libgdx

For the classes that were unable to be tested, this included AnimatedImage, BuffDisplayComponent and WeaponArrowProjectileComponent we created a testing plan which outlines our justification for choosing this method of testing rather than headless and how we tested these components.

See testing plan by clicking here.

Future Directions

A future direction for testing could be to investigate further into headless testing, which is a more complex version of testing. Furthermore the tests I have spoken about as being incomplete should be review to resolve the code coverage. Additionally edit the code further to allow for better testing, ensuring all getter and setters are not declared within methods and separate the functionality out of a single method.

Back to Combat Items Contents Page

Author

• Madison Feddema
• GitHub: MadiFeddema
• Discord: MadiFeddema
• Slack: Madison Feddema