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:

  1. UserService
  2. 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%