Testkonzept fuer das Spring Boot MVC "Card Game" Projekt
Einleitung
Dieses Testkonzept beschreibt Vorgehen, Testarten, Testdaten, Testumgebungen, Tools und CI-Integration fuer das Spring Boot MVC "Card Game" Projekt.
Zielsetzung
- Sicherstellung funktionaler Korrektheit der Backend- und UI-Komponenten.
- Automatisierte Tests bei Pull Requests und Releases.
- Einhaltung nicht-funktionaler Anforderungen: Responsetime < 0.8s in 95% der Fälle und klare Benutzerfuehrung.
- Reproduzierbare Testumgebungen mittels Testcontainers/Docker in CI.
- Coverage-Metrik >= 75\%
- Vordefinierte Testdaten und Testfälle
Umfang
- Backend: Spring Boot Controllers, Services, Repositories, DTOs, Validierungen.
- Persistenz:
- MariaDB fuer Karten-Definitionsdaten;
- MongoDB fuer Spielhistorie (Kartenverteilung, Spielzuege, Gewinner mit Timestamp).
- UI: Browser-basiertes Spiel (Chrome).
- Testarten: Unit, Integration, Komponenten-/Contract-Tests, E2E, Performance, Security, Smoke/Regression.
Annahmen / Abgrenzungen
- Maven als Build-Tool.
- Docker-Image-Deployment nach Build (Docker Hub).
- Keine externen APIs; keine Authentication.
- Staging-Umgebung vorhanden fuer volle Integrations- und Performance-Tests (optional mit geplanten Jobs).
Testarten und Vorgehen
Unit-Tests
- Frameworks: JUnit 5, Mockito, AssertJ.
- Fokus: Business-Logik, Service-Regeln, Validierungsregeln, Randfaelle, Exception-Flows.
- Mocking fuer Repositories/externale Komponenten.
- Abdeckung pro Klasse/sinnvoller Modulgrenze messen, damit Gesamt-Coverage >= 75\% erreicht wird.
Die konkreten Testfälle
| Nummer |
Testfallbeschreibung |
Eingabe |
Erwartetes Ergebnis |
| TC-01 |
Karte mischen gibt alle Karten zurueck |
Liste aller Karten |
Liste mit allen Karten in zufaelliger Reihenfolge |
| TC-02 |
Karte austeilen reduziert Kartenstapel |
Kartenstapel mit 52 Karten, Anzahl 5 |
Kartenstapel mit 47 Karten, Hand mit 5 Karten |
| TC-03 |
... |
... |
... |
Integrationstests
- Spring Boot Test mit realem Kontext, Testprofile.
- Testcontainers fuer MariaDB und MongoDB; bei Bedarf vordefinierte Images in CI-Caches verwenden.
- Datenbankmigrationen (Flyway) im Teststart ausfuehren bzw. Test-spezifische Migrationspfade nutzen.
- Failsafe-Plugin fuer IT-Lifecycle (
maven-failsafe-plugin, mvn verify).
- Fokus: Repository-Integration, transaktionales Verhalten, Mapping, Persistenz-Constraints.
Die konkreten Testfälle
| Nummer |
Testfallbeschreibung |
Eingabe |
Erwartetes Ergebnis |
| TC-50 |
... |
... |
... |
Komponenten-/Controller-Tests
MockMvc oder TestRestTemplate mit Testprofile, Eingabevalidierung, HTTP-Status, Fehler-Handling, DTO-Konversion. - Tests fuer MVC-Flows, Form-Validation und Response-Time-Basischecks (unit/integration level).
- Sicherstellen, dass Controller-Fehler angemessen behandelt und korrekte HTTP-Codes zurueckgegeben werden.
Die konkreten Testfälle
| Nummer |
Testfallbeschreibung |
Eingabe |
Erwartetes Ergebnis |
| TC-100 |
... |
... |
... |
End-to-End (E2E) Tests
- Szenarien: Spielstart (Kartenausgabe), Spielzug (Karte tauschen/ablegen), Spielende (Gewinneranzeige), UI-Navigation und Fehlermeldungen.
Die konkreten Testfälle
| Nummer |
Testfallbeschreibung |
Eingabe |
Erwartetes Ergebnis |
| TC-150 |
... |
... |
... |
- Tool: Gatling fuer Last- und Responsetime-Tests.
- Szenarien: typische Nutzerflow mit 2 Concurrent Users, Messung in 95% der Fälle Response-Time; CI-Smoke prueft RT < 0.8 s.
- Volle Last- und Langzeittests in Staging (grössere Datensätze).
- Tests parameterisierbar (URLs, Baselines, Zielwerte).
Die konkreten Testfälle
| Nummer |
Testfallbeschreibung |
Eingabe |
Erwartetes Ergebnis |
| TC-200 |
... |
... |
... |
Security Tests
- Statische Abhängigkeitspruefung:
dependency-check (OWASP), Snyk optional.
- Static Code Analysis: SpotBugs, Checkstyle.
- Dynamische Scans: OWASP ZAP in Merge/Release-Pipeline (Light in PRs, vollstaendig in Release/ nightly).
- Fokus: OWASP Top10-Checks (Injection, XSS, CSRF-Pruefungen, Sensitive Data Exposure, etc.). Da keine Auth vorgesehen, besonderes Augenmerk auf Input-Validierung und CSRF/Session-Handling.
Die konkreten Testfälle
| Nummer |
Testfallbeschreibung |
Eingabe |
Erwartetes Ergebnis |
| TC-250 |
... |
... |
... |
Testumgebungen
- Lokal (Developer): schnelle Unit-Iterationen; Testcontainers erlaubt Integrationstests lokal.
- CI (GitHub Actions, Hosted Runner): PR-Job (Unit + Static Checks + JaCoCo + kleiner E2E-Smoke), Merge-Job (Integration via Failsafe + Build Docker Image + Push zu Docker Hub).
- Staging: vollstaendige Integration + Performance (Gatling) + ausfuehrlicher ZAP-Scan.
- Produktion: nach Deployment automatisierte Post-Deploy Smoke-Checks (Endpoint-Health, kleine Funktionstests).