Skip to content
This repository has been archived by the owner on Apr 2, 2022. It is now read-only.

Technical Tests

Will Molloy edited this page Oct 26, 2017 · 1 revision

Unit (editor) tests:

  • Item spawning

These tests ensured items were only spawned once and sufficient item spawns were specified.
This was important because it ensured nothing was broken when making changes to NPC and/or items.

  • Game controller/persistence

These tests ensured the correct set of scenes were retrieved when querying a level and that persistence kept a record of both the initial and latest position of objects.
This was important for clearing persistence on a per level basis and ensured scenes could both reset objects to their initial positions and restore to their latest.

  • Lever events

These tests ensured levers moved their specified set of objects correctly when being activated once and moved them back when being activated twice.
There is also a test to ensure lever positions and state is maintained when changing scenes via. the persistence manager. Lever-persistence was difficult because it was not just the plate positions that had to be maintained but the movement direction and lever animation sprite.
The problem with this was lever state would be maintained throughout the other tests. To fix this an ID was assigned to each lever each test. This was achieved by including a counter in the [setup] method. This unit test was important because it was faster to run the unit test than switch test scenes in the game.

Currently the item-spawn tests are disabled as a last minute change was made to the game controller where the current scene is retrieved from the Unity-SceneManager. This means the game needs to be active (in play mode) to spawn items rather than in edit mode where the tests run. Otherwise all tests are passing.

Test Scenes

In addition to the unit tests tests scenes were creating to decrease development time.

The most important being the TEST-LEVERS scenes. This involved moving the player positions and portals so it was quick to switch scenes and ensure the lever state was maintained.

Other test scenes such as moving players and items near portals to test inventory persistence and moving players near spikes to test death mechanics were used.

Continuous Integration

TravisCI was eventually added to the project to run the editor tests. It wasn't too difficult to setup however the CI tool would take too long to run as it clones the entire repository then downloads and installs Unity. It was eventually disabled as it would have to run for every pull request which was slowing down our progress, users are now required to manually run the editor tests from their Unity installation. Currently the TravisCI tool throws an error. This is a time-out error which has occurred since the repository has reached ~600MB (currently > 800MB).

Clone this wiki locally