How and Why?

We use the user stories as a guide on what we will be acceptance testing. Before an official release of the mod, we want to make sure that the acceptance tests have been passed.

Our initial approach to testing in Milestone 1 was a combination of unit testing and integration testing with MCJunitLib. We chose to use these forms of testing at that time because the mod development was still in its infant stage and there were not a lot of in-game elements to test. Mostly we needed to test the logical execution of the code.

After Milestone 1, our mod development progressed more rapidly as we integrated more elements of the Space Invaders game into the world of Minecraft. Thus, we started to adopt more acceptance testing standards, where the testers can go into the game and interact with all the elements that have been implemented and record the results.

However, acceptance testing has some limitations. Our mod requires various items/blocks to be crafted with rare materials. Our team does not have a Survival Mode save state with all the materials to be able to test all the features. Thus, we had to use Creative Mode to obtain all the materials. However, Creative Mode has a limitation where items/weapons do not disappear or break, and enemies die very easily. Thus, we still used unit and integration testing for certain elements (like testing the breakage of the Arcade Machine and Space Invaders Trophy) using MCJunitLib. MCJunitLib can simulate a Survival Mode world without the need for the player to possess the required materials to craft our items.

We link the user stories and the Jira epic with an acceptance test in the traceability matrix. Each acceptance test has multiple components that need to be filled out by the tester when they go through the game. Only afterwards is a conclusion made on whether the feature being tested is accepted or rejected.

Example of an acceptance test form: