The system integration tests of the infrastructure classes of the Atlantis Sinks game should validate design choices from the developers’ and users’ perspective on all affected aspects of the existing game.
Tests should address:

• the current operation of the game
• the independent performance of the added modules
• the dependent performance of the added modules
• the added functionality or capability of the new feature
• the integration of the new feature with the existing infrastructure

The testing should validate the complete system operation with existing and appended components together. The test conclusion should provide the team with a high level of confidence that the program will work according to user requirements.

The system integration tests will consist of JUnit and user testing of all infrastructure classes in Atlantis Sinks to validate functionality and interaction design decisions. Direct and indirect testing of other dependent game classes and functions will be included in the overall integration testing process.
Other independent game classes and functions will not be included in the integration tests.

Atlantis Sinks is a RTS tower defence style single player game and is based on the LibGDX framework and developed in Java programming language. Atlantis Sinks uses entities, components, events, services, and resources as key aspects of its game engine architecture to make the development process and interaction easy.

• JUnit Best Practices Guide
• JUnit 5 User Guide
• LibGDX Documentation
• Atlantis Sinks Documentation

• Other game branches do not modify the current branch classes
• Key aspects and interface architecture of the main game are not changed
• Each successful build of the team's branch will have passed all unit testing before integration testing will commence with main branch

• Time complexity of going through all the test procedures for each modification to infrastructure may be infeasible

Test coverage will be outlined as:

• A table of testable requirements and the test cases addressing them
• A table of test necessity and the accompanied test case for all created tests If the outlined coverage levels are not met, software may not be released or further conversations and investigations will be conducted to ensure code and documentation are adequate.

Team 7's classes and methods of Atlantis Sinks along with all overlapping main interfacing components necessary to completely test the integrated featureset.

All agreed on user requirements from the design test plan will be tested.

The coverage of all JUnit test programs will be assessed using SonarCloud and test code analysis. Tests should cover at least 80% of the functionality of the program.

• JUnit Testing (Automated Software Testing)
• SonarCloud (Automated Software Testing Analysis)
• Interviews (Software User Testing)
• Peer-to-peer Conversations (Software Peer User Testing)

The following team members will be actively apart of managing and conducting the software integration testing:

Name	Title	Responsibilities
Jonathan Allen	Software Developer	Design and execute test cases for the infrastructure classes of Atlantis Sinks following the test plan appropriately.
Harland Jensen	Software Developer	Design and execute test cases for the infrastructure classes of Atlantis Sinks following the test plan appropriately.

Team reviews will also be conducted for all test cases created by the team. Team reviews include theoretical and practical reviews of the test plan, unit tests, test coverage, and test results. Team reviews will be held at the end of each sprint or after all major test integrations.

Task	Assignee	Deliverable
StructureFactory automated tests	Jonathan Allen	JUnit tests for StructureFactory
StructureService automated tests	Jonathan Allen	JUnit tests for StructureService
Structure Components automated tests	Harland Jensen	JUnit tests for structure components
Infrastructure integration tests (automated)	Harland Jensen	JUnit tests for infrastructure classes integrated into main branch (testing collaboration of game features)
Infrastructure integration tests (user testing)	Jonathan Allen Harland Jensen	User testing for all infrastructure classes (focusing on gameplay operations/reliability/functionality)

4.1 Sprint 2

4.1.1 Infrastructure classes

4.1.1.1 Creation of structures

• Structures can be created and added to the entities list
• All structures have a unique name
• Structures are rendered by the game engine

4.1.1.2 Deletion of structures

• Structures can be deleted and removed from the entities list
• Structures are disposed of correctly without memory leakage

4.1.1.3 Integrated placement of structures

• Structures must be able to be placed on the map
• Structures must not be able to be built on other game entities
• Structures should not be able to be placed on non-buildable tiles
• Structures should conform to the world grid system

4.1.1.4 Variety of structure capabilities (components)

• Components for different types of structure should be tested
• Different structures with different added components must act different and provide different functionality

4.1.1.5 Capability to change or extract structure attributes in the game

• A structure entity must be able to be selected
• A structure entity must be able to change specific descriptive attributes upon request
• A structure entity must be able to provide specific descriptive attributes upon request

4.1.2 Integration tests with dependent Atlantis Sinks classes

4.1.2.1 Integration of structures with the building UI

• Appropriate testing must be present to test the structures side of building UI integration

4.1.2.2 Integration of structures with enemies

• Appropriate testing must be present to test the structures side of enemy integration

4.1.2.3 Integration of structures with shop

• Appropriate testing must be present to test the structures side of shop integration

4.2 Sprint 3

4.2.1

4.2.1.1

4.2.1.2

4.2.1.3

4.2.2

4.2.2.1

4.2.2.2

4.2.2.3

• Other game features of Atlantis Sinks that have no direct interaction with infrastructure classes

For all requirements and features, the tester will perform JUnit tests and user testing as defined previously. Each test performed will provide the tester with data regarding the result of the test and the expected result of the test, for unit tests and user tests. The summed results of the tests are then evaluated and analyzed. The passed tests are noted, and the failed tests or associated classes are revised.

The tests will be run in a predefined order relative to the Gradle build order. With each version and build of the game the tests will be performed as follows:

6.1.2.1 Sprint 2

Infrastructure class features:

1. Structure creation
2. Structure deletion
3. Integrated placement of structures
4. Structure components
5. Obtaining attributes of structures

Integration of structures:

1. Building UI integration
2. Enemies integration
3. Shop integration

6.1.2.2 Sprint 3

Unified Grid System class:

Integration of the Unified Grid System:

• Unit tests must have a coverage of greater than 60%
• All unit tests must pass without exception
• Feature must be tested by at least 10 different people
• User testing must pass with greater than 70% acceptance of feature
• Integration tests must not break main branch
• Integration tests must result in 99.99% integration of structure feature without disrupting other game features

All defects found by the test procedure must be recorded and addressed. Defects will be labelled from low, medium, high, to critical.

Level	Description
Low	Defect hinders the optimal performance of the feature
Medium	Defect hinders the performance of the feature
High	Defect breaks the functionality of the feature branch
Critical	Defect breaks the functionality of the main branch

Critical, high, and medium defects must be addressed immediately by team member leading the tests of the defective feature. Low defects can be reviewed in the team review and addressed at a later time.