J Unit Test ‐ Survey Master ‐ DONE - IU-Internationale-Hochschule-Augsburg/fallstudie-thema-2-online-umfragesystem GitHub Wiki
SurveyMaster: Testdokumentation
Einführung
Dieses Dokument beschreibt die Gedanken hinter dem Testingprozess für das Online-Umfragetool SurveyMaster.
Grundsätzlich wird eher breit als tief getestet. Eine hohe Testabdeckung wird als höheres Gut eingeschätzt als die Abprüfung eines jeden Grenzfalls. Letztere werden zwar nicht vernachlässigt, aber aufgrund von ressourcenbasierten Beschränkungen gilt:
Coverage > Depth
Es werden außerdem nur Controller- und Service-Klassen getestet. Nur wo Methoden sind, können Testmethoden konstruiert werden.
Zu testende Komponenten
- LoginController
- ParticipantSurveyController
- QuestionController
- QuestionService
- SurveyController
- SurveyService
- UserService
Grundsätzlich ist davon auszugehen, dass "good" und "bad" Inputs jeweils ein zufriedenstellendes Testergebnis liefern, d.h. ein richtiger (good) Wert muss funktionieren, ein falscher (bad) Wert darf nicht funktionieren.
Ist dieser Zustand erreicht, gilt der Test als bestanden. Dann kann der nächste Test begonnen werden.
Exemplarische Dokumentation zweier Testklassen (UserService und SurveyController)
1. Übersicht
Diese Dokumentation beschreibt die JUnit-Tests für zwei Klassen:
- UserService
- SurveyController
Die Tests wurden mit JUnit 5 und Mockito erstellt und fokussieren sich auf eine breite Testabdeckung statt auf Testtiefe. Da sich die Idee hinter den Testmethoden stetig wiederholt, soll die Doku dieser beiden Klassen exemplarisch für das gesamte Testvorgehen stehen, um keine unnötigen Redundanzen einzubauen.
2. UserServiceTest
2.1 Zu testende Klasse
UserService
2.2 Testmethoden
2.2.1 testLoadUserByUsername_UserFound()
- Zweck: Überprüft, ob ein Benutzer korrekt geladen wird, wenn er existiert.
- Erwartetes Ergebnis:
- UserDetails-Objekt wird zurückgegeben
- Benutzername und Passwort stimmen überein
- Benutzer ist aktiviert und nicht gesperrt
- Benutzer hat die Rolle "USER"
2.2.2 testLoadUserByUsername_UserNotFound()
- Zweck: Überprüft das Verhalten, wenn ein nicht existierender Benutzer geladen werden soll.
- Erwartetes Ergebnis: Null wird zurückgegeben
2.3 Mocks
- UserRepository wird gemockt, um die Datenbankinteraktionen zu simulieren.
3. SurveyControllerTest
3.1 Zu testende Klasse
SurveyController
3.2 Testmethoden
3.2.1 testGetSurveyAdmin()
- Zweck: Testet die Anzeige der Umfragen für einen Admin-Benutzer.
- Erwartetes Ergebnis:
- Gibt "surveyView" zurück
- Fügt SurveyView-Objekt zum Model hinzu
3.2.2 testLoadAddSurveyView()
- Zweck: Überprüft das Laden der Ansicht zum Hinzufügen einer Umfrage.
- Erwartetes Ergebnis:
- Gibt "addSurvey" zurück
- Fügt SurveyForm-Objekt zum Model hinzu
3.2.3 testButtonHandlerDelete()
- Zweck: Testet die Löschfunktion einer Umfrage.
- Erwartetes Ergebnis:
- Leitet zur survey-admin Seite weiter
- Ruft deleteSurvey-Methode auf
3.2.4 testButtonHandlerEdit()
- Zweck: Überprüft die Bearbeitungsfunktion einer Umfrage.
- Erwartetes Ergebnis:
- Gibt "questionsView" zurück
- Fügt QuestionsView-Objekt zum Model hinzu
3.2.5 testSaveSurveyNew()
- Zweck: Testet das Speichern einer neuen Umfrage.
- Erwartetes Ergebnis:
- Leitet zur survey-admin Seite weiter
- Speichert neue Umfrage in der Datenbank
3.2.6 testSaveSurveyExisting()
- Zweck: Überprüft das Aktualisieren einer bestehenden Umfrage.
- Erwartetes Ergebnis:
- Leitet zur survey-admin Seite weiter
- Aktualisiert bestehende Umfrage in der Datenbank
3.2.7 testLoadAddSurveyViewAgain()
- Zweck: Testet das erneute Laden der Ansicht zum Hinzufügen einer Umfrage.
- Erwartetes Ergebnis:
- Leitet zur survey-admin Seite weiter
- Fügt SurveyView-Objekt zum Model hinzu
3.3 Mocks
- SurveyRepository, QuestionService, SurveyService und Model werden gemockt.
4. Anmerkungen
- Die Tests konzentrieren sich auf eine breite Abdeckung verschiedener Szenarien.
- Es werden hauptsächlich "gute" und "schlechte" Fälle unterschieden, um die Testabdeckung zu erhöhen.
- Mockito wird verwendet, um Abhängigkeiten zu simulieren und das Verhalten zu kontrollieren.
5. Voraussetzungen
- JUnit 5
- Mockito
- Spring Framework (für Dependency Injection und Modell-Attribute)
Diese Testdokumentation bietet einen Überblick über die durchgeführten Tests und deren Zweck. Sie dient als Referenz für Entwickler und QA-Teams, um die Funktionalität und Robustheit des UserService und SurveyController zu verstehen und zu überprüfen.
Finale Testcoverage:
Controllerklassen: 100%
Serviceklassen: 100%
Entityklassen: 100%