Buildables Team Sprint 2 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.

PlaceableEntity

To test the PlaceableEntity class we used mock testing with white box testing. We tested that the class called the necessary function on components for the new functions which were:

• placed
• willPlace
• removed
• willRemove

CostComponent

The cost component test used mocking to test its' interactions with other classes. We decided to do white box testing for this class since it requires an intricate knowledge of how it interacts with other classes. When creating the testing plan for this class, we thought through the different cases which were possible with this class. The cases we came up with were:

• Placed with not cost
• Placed with one cost
• Placed with multiple costs
• Removed with no health component and no cost
• Removed with no health component and one cost
• Removed with no health component and multiple costs
• Removed with health at 100% and no cost
• Removed with health at 100% one cost
• Removed with health at 100% and multiple costs
• Removed with health at 50% one cost
• Removed with health at 50% and multiple costs
• Removed with health at 0% one cost
• Removed with health at 0% and multiple costs We then created a test for each of these cases. We additionally verified it by placing down structures with a cost in the game and checking that the appropriate resource meter was depleted.

RotationRenderComponent

While this component didn't end up being used for this sprint due to time constraints, we still decided to test it in case we wished to use it for future sprints. For this test we employed both mock testing and assertions so we could test both the internal state and the classes interactions with other classes. We did white box testing since we needed to know what classes it interacted with. For the cases, we thought up what all the possibilities could be. Because it relies on the Rotation enum, there only ended up being 4 possibilities.

• Rotation.NORTH
• Rotation.SOUTH
• Rotation.EAST
• Rotation.WEST These tests were then implemented, and we checked that the state was updated through the set method and we also checked that the textureAtlas was asked for the new rotation region.

StructureDestroyComponent

For this class, we decided to use mock testing to test its interactions with other classes. Since there is no internal state for the class, we didn't use any assertions and we decided to use White box testing since we needed to know how it interacted with other classes. We thought up two possible cases to test. Those being an update when the component is not dead, and an update when the component is dead. We then verified that the structure was removed from the StructurePlacementService if dead and wasn't removed if not dead.

StructureToolPicker

To test the StructureToolPicker we decided to use both assertions and mock testing. This is due to the fact that it's interactions with tools is paramount to its functionality, but we also wanted to test the internal level state. We used the white box methodology to create the test cases since we needed to know how it interacted with the tools. The cases we came up with were:

• setLevel updating the level state.
• that dispose unregisters the StructurePicker from the render service
• that show and hide successfully show and hide the ui
• that setSelectedTool successfully changes which tool is selected
• that interact successfully interacts with the selected tool

ToolsConfig

To test the tools config file, we decided to use assertion testing with the black box methodology. To test it, we read in the structure_tools.json config file and verified that all the required properties were set. We also verified that the tool classes the config files refers to exist, can be instantiated with the required arguments, and are instances of the Tool class.

Tools

Tool

To test the abstract tool class, we created a MockTool class as follows:

class MockTool extends Tool {
    public MockTool(ObjectMap<String, Integer> cost) {
        super(cost);
    }

    @Override
    public boolean interact(Entity player, GridPoint2 position) {
        return false;
    }
}

We then used this class to ensure that the cost passed to the tool was the same that was returned.

Healing

[Yugansh Pancholi]

For testing the functionality of healing.java, firstly we placed both walls and turrets in the game area. Then we lured the enemies to attack us and hid behind these structures for them to take damage. Damage to walls and turrets was then healed by pressing 3 and T-key respectively on keyboard, which is a command in game to open the toolbox and selecting healing icon. Once selected, we clicked on damaged walls and turrets which restored their health to maximum.

PlacementTool

To test the abstract PlacementTool class, we created a MockPlacementTool class as follows:

class MockPlacementTool extends PlacementTool {

    public MockPlacementTool(ObjectMap<String, Integer> cost) {
        super(cost);
    }

    @Override
    public PlaceableEntity createStructure(Entity player) {
        return mock(PlaceableEntity.class);
    }
}

We then used this mock class to ensure that the interact function successfully checked if the player had the required funds and, if so, successfully placed the structure returned from createStructure.

BasicWallTool / GateTool / TurretTool

To test the implementations of the PlacementTool we used white box testing to see what was being overridden. For these classes, only the createStructure method was being overridden, therefore we only created tests to ensure that a structure was successfully returned from this method.

IntermediateWallTest

Since this tool also overrides the interact function, we used more extensive test cases for this class. We used mock testing to verify that it interacted with other classes as intended. The cases we came up with through the white box methodology were:

• test interact with no existing structure and no cost
• test interact with existing structure and no cost
• test interact with existing wall and no cost
• test interact with existing wall and sufficient funds
• test interact with existing wall and insufficient funds
• test interact with no existing structure and sufficient funds
• test interact with no existing structure and insufficient funds