Team‐7 Testing Plan

Overview

This wiki page details the test plan that team 7 followed, which ultimately allowed the team to quickly identify potential errors, and ensure that all of the code written follows it's intended purpose. Additionally, as this project is worked on by several teams at once, all on different feature branches, it is important that all code is working properly before merging it into the main branch.

Testing procedure

1. Before writing any new code, some of the required methods/member variables should be identified were possible. This will give the team a brief overview of the overall workings of the class before having to implement it.

2. Ideally, unit tests should be written before the implementation of various features; however, sometimes this is not possible, and therefore should be completed afterwards.

3. Steps 1 and 2 are applicable for most cases, and a test suite for a class can be written. These unit tests allow for quick error identification and ensure that any new features added did not break existing ones.

4. Once unit tests were completed, they should be run alongside the other tests available in the test suite. The game should then be built and run manually to ensure that basic functionality is maintained.

5. Once the features were confirmed to be working, and the implementation was confirmed with another team member, a pull request should be made allowing both the team and the entire studio to look at any changes that you have made, and provide feedback/ask questions.

6. Once this pull request is approved by the majority of the team, it should be merged into the main branch and it should be confirmed that this merge had no undesired changes.