Skip to content

Boss_dialogue_box_testplan

LI WANGXIN edited this page Oct 19, 2026 · 1 revision

[Team1] Boss Dialogue Box Test Plan

This page covers the testing approach for the Boss dialogue box, including BossDialogueComponent, BossDialogueConfig, Boss phase events, and card-play blocking.

Testing policy

  1. Tests ship with the code. Changes to Boss dialogue behaviour must include the relevant tests in the same pull request.
  2. Logic is unit tested. Dialogue lifecycle, configuration validation, animation frames and card blocking are verified automatically.
  3. Visual behaviour is checked manually. Final positioning, artwork quality and animation smoothness are verified by running the Boss battle.
  4. Tests and coverage are checked before merge.

Coverage thresholds

The project requires 90% instruction coverage and 80% branch coverage, enforced by JaCoCo.

Run from the source/ directory:

./gradlew clean test
./gradlew jacocoTestReport

The HTML report is written to:

source/core/build/reports/jacoco/test/html/index.html

Components being tested

Component under test Test class
BossDialogueComponent BossDialogueComponentTest
BossDialogueConfig BossDialogueConfigTest
BossAI phase events BossAITest
BattleController card blocking BattleControllerTest

What the tests cover

  • Configuration loading - the production JSON loads all three dialogue entries, invalid entries are rejected, and all sprite sheets have the expected dimensions.
  • Dialogue lifecycle - the opening dialogue appears during creation, phase dialogues appear when the Boss changes phase, and each phase is displayed only once.
  • Animation - animation starts at frame zero, advances through the configured frames and remains within the 30-frame limit.
  • Dismissal - clicking the overlay or reaching the configured duration closes the dialogue.
  • Card protection - card submission is blocked while dialogue is visible and restored after dismissal.
  • Boss phase integration - Phase Two and Enraged events trigger the correct dialogue, while removed listeners receive no later events.
  • Cleanup - disposing the component removes the overlay, restores card input and unregisters the phase listener.

What cannot be unit tested

Some visible behaviour must be confirmed by running the game:

  • Artwork quality - verify that the correct dialogue artwork is readable and is not stretched.
  • Animation smoothness - verify that the 30 sampled frames play smoothly without flickering.
  • Boss-relative positioning - verify that the dialogue appears near the Boss and remains inside the screen at different window sizes.
  • UI input blocking - verify that cards cannot be clicked or dragged while the overlay is visible.
  • Full battle integration - verify that opening, Phase Two and Enraged dialogue appear correctly during a complete Boss battle.

Known gaps

  • There is no pixel-perfect automated test for the rendered dialogue position.
  • Visual animation quality depends on manual desktop testing.
  • BattleScreen asset loading and unloading are mainly verified through integration and manual testing rather than isolated unit tests.

Table of Contents

Home

Game Engine

Getting Started

Entities and Components

Service Locator

Loading Resources

Logging

Unit Testing

Debug Terminal

Input Handling

UI

Animations

Audio

AI

Physics

Game Screens and Areas

Terrain

Concurrency & Threading

Settings

Encounters
Tutorials and Contextual Help (Team 2)
Cards (Team 6)
Story (Team 6)
Level design, battle system, turn order, spawn (Team 3)
Cards, Save/Load & Bestiary (Team 5)
Rewards and Battle Settlement (Team 7)

Troubleshooting

MacOS Setup Guide

Clone this wiki locally