Ship & Extractors Team Sprint 2 Test Plan

We also made several tests in the Configuration and MapGameArea Test Plan this sprint

Extractor Animations

We plan to use mock testing to ensure that the expected animations function as intended, when intended.

Extractor Resource Bar

The new changes to the extractor resource bar are very minor. These involve rounding the width of the bar to be pixel perfect, and updating the width of the extractor bar. There is no in-engine functionality that references these values, and any testing would be heavily dependent on the internal state of the classes or require a way to analyze the user input "visually". As such, these are left to user testing, as it is very clear if they ever stop working to a user.

Popup Component

This shares a lot of similarities to the extractor resource bar, however it does have actual functionality in the engine that can be tested. The visual elements are again difficult to test without heavy white box testing, however:

• The popup should move at a predictable rate and path, which should be verified.
• The popup should despawn at a specific time properly and be removed from the entities, which should be verified.

The first point can be checked using rather simple unit tests. Checking for the second point however is not possible due to how the engine is set up in testing, there is no way for a test to check if an entity has been removed. As such, this will need to be left to user testing.

Additionally, in order to ensure the popup factory cannot fail if a new resource type is added in future, but not an icon associated, there will be a test case that ensures all resources have an associated icon.

Extractor Placement Tool

The extractor placement tool inherits most functionality from its parent class which is well tested. The major distinction is its rejection function depending on the count of extractors. As such, this will need to be tested. This can be done with simple unit tests which verify the rejection functions correct outputs given various fixed state inputs which have known results. The maximum values of extractors themselves are stored in the gamestate, and as such tested as part of the gamestate test suite, their initialization is heavily level dependant and experimental (will change regularly, no final plan) so this does not need to be tested yet, if at all.