Testing Plan ‐ BirdieDash Mini Game - UQcsse3200/2024-studio-2 GitHub Wiki

Testing Plan for BirdieDash Mini-Game

This wiki outlines the testing plan for the BirdieDash mini-game, covering the testing approach, key testing files, and components that require visual checks instead of traditional unit tests. The focus is on ensuring the proper functionality of game entities, renderers, and screen interactions.

Testing Approach

1. Unit Testing

  • Objective: To test that the individual game components are correctly and properly interacting.
  • Scope: Focussing on testing the primary entities (Bird, Coin, Pipe, Spike), ensuring each of the classes behaves as expected during gameplay.

2. UI/Visual Checks

  • Objective: Ensuring that all visual elements are displayed correctly and interact smoothly within the game.
  • Scope: Includes verifying animations, screen transitions, and responsiveness to user input.

Testing Files

Key files for unit testing the BirdieDash mini-game components include:

  1. BirdTest.java

    • Testing the behaviour and movement of the bird, including responses to player input and collision detection with other game objects (Pipes, Coins, and Spikes).
      View Source

  2. CoinTest.java

    • Ensuring that the coin component functions correctly, particularly its interaction with the bird (when collected) and disappearance upon collection.
      View Source

  3. PipeTest.java

    • Validating the Pipe's behaviour, ensuring it moves correctly and triggers appropriate game events upon collision with the bird.
      View Source

  4. SpikeTest.java

    • Confirms the proper interaction between the bird and the spikes, including triggering game over events upon collision.
      View Source

  5. CollisionHandlerTest.java

    • Confirm if collisions between the bird and pipes, coins, or spikes trigger appropriate game events, such as increasing the score or ending the game. View Source

Classes Unable to Be Tested

Some components of the BirdieDash mini-game require visual confirmation rather than unit testing, as they involve graphical rendering or complex screen interactions.

  1. BirdieDashGameScreen

    • Works as expected if the bird, pipes, coins, and spikes are displayed and interact correctly. The screen should transition appropriately between game states (e.g., start, game over) and respond to player input such as spacebar for jumping or key presses for pause/restart.

  2. BirdRenderer, CoinRenderer, PipeRenderer, SpikeRenderer

    • Each renderer class is visually confirmed if the corresponding game entities (Bird, Coin, Pipe, Spike) appear as expected on the screen and animate or interact correctly during gameplay.

  3. BackgroundRenderer

    • Works as expected if the background scrolls smoothly during gameplay, without any glitches or interruptions.

Visual Checks

To confirm the visual elements work are working fine:

  • BirdieDashGameScreen should display all entities, such as the bird, pipes, spikes, and coins. User inputs (spacebar for jumping) should be responsive.
  • BirdRenderer, CoinRenderer, PipeRenderer, SpikeRenderer should ensure smooth animations and that all objects appear correctly.