Integration Team Sprint 3 Test Plan

For testing in this sprint, we planned to use primarily mock based testing to ensure that our classes interacted with other classes in the expected manner. We also did some assertion testing for classes which maintained state, such as the CostComponent class.

ColorDrawable

To test the ColorDrawable we used mocking to test its' interactions with other classes. Due to the fact that we used mocking, we utilised the white box testing methodology since we needed to know how the ColorDrawable interacted with the render batch in order to verify its functionality. Since it is a fairly simple class, there weren't too many methods to test. For the draw method, we simply tested it with a variety of inputs to ensure that each of the colors worked as intended. For the setAlpha method, we verified that the batch was drawn with the new alpha after setAlpha was called since there are no public getters defined for alpha.

AlertUIComponent

For the AlertUIComponent, mockito testing was used to verify its' interaction with other classes. Some assertion testing was also used for the setAlpha method since we could test the state through the public getAlpha method. Due to the use of mockito, we used a mixture of white box and black box testing since we needed to know how it interacted with other classes for some test cases while others could simply check state. A test case was implemented for each of the following methods.

create

For this test case, the create method was called on the component and we used mockito to verify that it was successfully registered with the renderService.

draw

For this test case, the 'draw' method was called on the component. Since the draw is handled by the table within the component, there is no way to verify that the batch actually drew, however we did at least verify that the entity's position was access which is a requirement for drawing it successfully to the screen.

setAlpha

For this test case, the setAlpha method was called on the component, and then the state was checked via assertEquals and the getAlpha method.

ActionFeedbackComponent

For the ActionFeedbackComponent only mockito testing was utilised since the class didn't store any state. Due to the sole use of mockito testing, only white-box test cases could be implemented since we were required to know how each method interacted with other classes. The following methods had test cases created for them.

create

To test the create method, we used mockito to verify that the displayWarning and displayWarningAtPosition events were successfully registered with the entity and that the functions they pointed to have the expected number of parameters.

displayWarning

To test the displayWarning method, mockito was used to verify that a new entity was placed at the component's entity's position.

displayWarning

To test the displayWarningAtPosition method, mockito was used to verify that a new entity was placed at the position passed to the method.

SoundComponent

To test the SoundComponent class, mockito and white-box testing were used to verify that each function interacted with other classes as intended. This is due to the fact that there is no public state for the class, so assertions could not be used. The following methods had a test case implemented.

create

The create method was tested via mockito verifications. The first verification is to ensure that the given sound files are retrieved from the resourceService. There were also verifications made to ensure the required events were registered with the entity, and that the functions they pointed to have the expected number of parameters. The expected events are:

• playSound
• loopSound
• stopSound

playSound

To test the playSound method, mockito verifications were used to verify that the sound mapping to the given soundName was successfully played. This was performed 3 times at 3 different volume levels to ensure that the sounds respected the UserSettings.

loopSound

To test the loopSound method, mockito verifications were used to verify that the sound mapping to the given soundName was successfully looped. This was performed 3 times at 3 different volume levels to ensure that the sounds respected the UserSettings.

stopSound

To test the stopSound method, mockito verifications were used to verify that the sound mapping to the given soundName was successfully stopped.

ParticleComponent

To test the SoundComponent class, mockito and white-box testing were used to verify that each function interacted with other classes as intended. This is due to the fact that there is no public state for the class, so assertions could not be used. The following methods had a test case implemented.

create

The create method was tested via mockito verifications. The first verification is to ensure that the given effect files are retrieved from the resourceService. There were also verifications made to ensure the required events were registered with the entity, and that the functions they pointed to have the expected number of parameters. The expected events are:

• startEffect
• stopEffect

startEffect

To test the startEffect method, mockito verifications were used to verify that the sound mapping to the given effectName were successfully played.

stopEffect

To test the stopEffect method, mockito verifications were used to verify that the sound mapping to the given effectName were successfully stopped.

ExplosiveComponent

To test the ExplosiveComponent, mockito verifications were used. This required the use of the white-box testing methodology since it requires intricate knowledge of how the class interacts with other classes. Since there is no public state stored in the ExplosiveComponent, not assertion testing has been performed. The chainExplode method could not be tested since it used the postRunnable method to trigger the explosion. The following methods had test cases created for them.

create

For this test case, mockito was used to verify that the expected events where registered with the entity with the expected number of parameters for their methods. The events that are expected to be added are explode, and chainExplode.

explode

To test the ExplodeComponent mockito verifications were used to ensure that a new entity was placed at the expected location when the explode event is triggered on the components entity.

There were also two additional test cases to test the damage and the chain functionalities respectively. To test the damage functionality, mockito verifications were used to ensure that entities with the CombatStatsComponent which are in the range of the explosive are correctly damaged.

To test the chain functionality, mockito verifications were used to ensure that explosives within the specified range have the chainExplode event triggered.

ExplosiveBarrelTool

To test this class, assertion testing was used. Since the class only overrides one method, only createStructure was tested. The remaining methods defined in the parent class are tested in other test files.

createStructure

Two test cases were created for this method. One creates a structure with no cost and the second creates a structure with a cost. assertNotNull is used to ensure that a structure was successfully returned.

LandmineTool

To test this class, assertion testing was used. Since the class only overrides one method, only createStructure was tested. The remaining methods defined in the parent class are tested in other test files.

createStructure

Two test cases were created for this method. One creates a structure with no cost and the second creates a structure with a cost. assertNotNull is used to ensure that a structure was successfully returned.

ProximityTriggerComponent

To test this component, mockito verifications were used to test its integration with other classes. This is due to the fact that no public state is accessible for the class. As such, white-box testing was used since it was necessary to understand how the class interacted with other classes. Test cases were created for the update function. The test cases utilise mockito verifications to ensure the triggerFunction is triggered or not triggered depending on the entities returned from the EntityService. The following test cases were implemented:

• trigger function is called with one flag entity in range.
• trigger function is not called with one flag entity out of range.
• trigger function is called when the flag entity is equal to the range.
• trigger function is called when there is a single entity in range and the rest are out of range.
• trigger function is called only once when there are multiple flag entities in range.
• trigger function is never called with multiple flag entities out of range.