Dieser Bericht dokumentiert die Qualitätssicherung von CoinDash und prüft, ob die im Software-Qualitätskonzept (Stand 09.04.2026) gesetzten Ziele erreicht wurden. Alle Kennzahlen wurden auf dem Stand des main-Branches gemessen, dem integrierten und auslieferbaren Stand des Projekts.
Das Qualitätskonzept orientiert sich an ISO/IEC 25010 und stellt nicht fehlerfreie, sondern eine funktionierende, stabile und benutzbare Software in den Vordergrund. Massgeblich sind vier Merkmale, gegen die in diesem Bericht ausgewertet wird:
Alle Spielentscheidungen werden serverseitig getroffen und durchgesetzt. Punkte, Kollisionen und Power-Ups verhalten sich regelkonform.
Verbindungsabbrüche einzelner Clients werden erkannt und behandelt, ohne Server oder laufende Sitzungen zu beeinträchtigen.
Die Schichtung in Client, Server und Main ist sauber getrennt, sodass Änderungen lokal begrenzt und nachvollziehbar bleiben.
Geringe, gleichmässige Latenz bei der Zustandssynchronisation für flüssiges Echtzeit-Gameplay.
Qualität wird auf zwei Ebenen betrachtet: den technischen Eigenschaften des Systems und dem Erlebnis aus Sicht der Spielenden. Technische Eigenschaften prüfen wir automatisiert und metrisch. Das Spielerlebnis (Spielbarkeit, Korrektheit im Betrieb, Robustheit) lässt sich kaum automatisiert testen und wird daher durch manuelle Spielsitzungen verifiziert. Das Qualitätskonzept benannte als nächsten Schritt explizit den gezielten Ausbau der Testabdeckung mit Fokus auf die Serverseite. An diesem Anspruch misst sich der vorliegende Bericht.
Die Qualitätssicherung kombiniert automatisierte und manuelle Massnahmen, die fest im Entwicklungsprozess verankert sind.
Automatisierte Tests
Als Testframework dient JUnit 5 (JUnit Jupiter), ausgeführt über ./gradlew test. Der Schwerpunkt liegt bewusst auf der serverseitigen Spiellogik und dem Netzwerkprotokoll, wo die kritische und am schwersten manuell verifizierbare Logik konzentriert ist:
ServerGamestate (Kollision, Münz-Spawn, Power-Ups), LobbyManager, ScoreManager, NicknameAllocator sowie Lobby- und Login-Abläufe.ClientGamestate, PlayerInputHandler, SoloHighScoreManager, TutorialSession).Coverage-Messung
Die Testabdeckung wird mit JaCoCo erhoben (./gradlew jacocoTestReport) und nach Paketen aufgeschlüsselt, um Lücken gezielt sichtbar zu machen. Zusätzlich liefert JaCoCo die zyklomatische Komplexität als Wartbarkeitsindikator.
Manuelle Spieltests
Vor grösseren Integrationsstufen führen wir Multiplayer-Sitzungen mit zwei bis sechs Spielenden durch. Geprüft werden Spielbarkeit und Reaktionsfähigkeit der Steuerung, regelkonformes Verhalten von Punkten, Kollisionen und Power-Up-Effekten sowie gezielt Robustheitsfälle, insbesondere der Abbruch einzelner Clients während einer laufenden Runde.
Prozess & Qualitäts-Gate
Wir arbeiten mit Feature-Branches und Conventional Commits (feat, fix, chore, docs), die Bugfixes klar von Features trennen. Kritische Änderungen werden in gemeinsamen Code-Reviews im Team besprochen. Log4j2 protokolliert Verbindungsabbrüche, Spielzustandsübergänge und Protokollfehler zur Laufzeit. Der reproduzierbare Build ./gradlew build-cs108 bündelt clean, test, jar und javadoc. Ein fehlschlagender Test verhindert ein auslieferbares Artefakt und wirkt damit als Qualitäts-Gate.
Alle Tests sind grün. Gegenüber dem Qualitätskonzept hat sich die Testbasis nahezu vervierfacht und die Codeabdeckung etwa verdoppelt. Die kleineren Vergleichswerte unter den Kennzahlen zeigen den Stand 09.04.2026.
Die serverseitige Abdeckung liegt bei 53% (Instruction) bzw. 42% (Branch), das Protokoll-Paket main bei 78% / 56%. Die kritische Spiellogik ist damit substanziell abgedeckt. Das clientseitige Paket bleibt bei 14% / 10%, da dort JavaFX-/UI-Klassen dominieren, die ohne UI-Harness kaum automatisiert prüfbar sind und bewusst manuell verifiziert werden. Die durchschnittliche zyklomatische Komplexität von 2.47 pro Methode liegt weiterhin in einem gut handhabbaren Bereich. Der Codeumfang ist von 5 802 LOC (Stand Konzept, 09.04.2026) auf 16 168 Zeilen gewachsen (12 072 Java-Produktivcode), also rund das Dreifache. MainController (1 545 LOC) und GameController (1 467 LOC) sind die grössten Dateien.
Bewertung der Resultate gegen die vier Qualitätsmerkmale des Konzepts:
Die server-autoritative Spiellogik ist durch 88 grüne Tests abgesichert, ServerGamestate und das Protokoll sind gezielt abgedeckt. Manipulierte Clients bleiben wirkungslos.
Verbindungsabbrüche werden über Heartbeat erkannt. Disconnect-Szenarien sind durch Server-Tests und manuelle Sitzungen verifiziert.
Die Schichtung ist sauber und die Komplexität niedrig. Offen bleiben MainController und GameController als Refactoring-Kandidaten sowie die bei Gettern lückenhafte JavaDoc.
Die Echtzeit-Synchronisation läuft in manuellen Sitzungen mit zwei bis sechs Spielenden flüssig, ohne spürbare Latenzprobleme.
Zielerreichung
Das im Konzept gesetzte Ziel, der gezielte Ausbau der Testabdeckung mit Fokus auf die Serverseite, wurde erreicht. Die Serverabdeckung stieg von einem niedrigen Niveau auf 53%, und die Gesamtabdeckung verdoppelte sich. Die niedrige Client-Abdeckung von 14% ist die bewusst in Kauf genommene Folge der Entscheidung, UI-nahe Logik manuell statt automatisiert zu verifizieren. Sie ist eine bekannte und vertretbare Einschränkung und kein unentdecktes Risiko.
Offene Punkte
Zum Projektabschluss bleiben einige Punkte offen. Es fehlen automatisierte UI- und End-to-End-Tests sowie eine CI-Pipeline, weshalb die Qualitätsschritte lokal über den build-cs108-Build durchgesetzt werden. Die Effizienz ist nur qualitativ über Spielsitzungen belegt, nicht durch systematische Last- und Latenzmessungen. Eine Fortführung würde die grossen Klassen MainController und GameController aufteilen, die JavaDoc auf den öffentlichen Schnittstellen vervollständigen und das bestehende Qualitäts-Gate über eine schlanke CI automatisieren.
Fazit
Zum Abschluss des Projekts sind die im Qualitätskonzept definierten Ziele im Wesentlichen erreicht. Die Architektur ist stabil, die kritische Spiellogik ist getestet und grün, und die Testabdeckung wurde planmässig ausgebaut. Die verbleibenden Punkte betreffen Wartbarkeit und Testautomatisierung. Sie sind bekannt, eingegrenzt und priorisiert und gefährden den ausgelieferten Funktionsumfang nicht. CoinDash wird in einem stabilen und spielbaren Zustand ausgeliefert.