Skip to main content

Testsuite

Einige Tests erfordern die Konfiguration von Zugangsdaten als Umgebungsvariablen vor Ausführung. Diese Umgebungsvariablen sind zu setzen: SUBATO_TASK_POOL_SYNC_GIT_USER, SUBATO_TASK_POOL_SYNC_GIT_TOKEN (siehe Konfiguration)

Fixtures​

In den Tests werden Fixtures verwendet, welche die Testdaten darstellen.

Für die Testumgebung existiert eine Konfiguration (src/test/resources/application-testsuite.yml), welche die Konfiguration in src/main/resources/application.yml überschreibt. Für die Tests wird eine H2 In-Memory Datenbank verwendet. Bei Start der Integration Tests wird eine Verbindung zu der Datenbank aufgebaut, wodurch alle Repositories die Daten daraus ziehen. Repositories/Services sind im Fall von Unit-Tests zu mocken, wenn nötig.

src/test/resources/data.sql​

Die SQL-Datei wird zu Beginn der Tests für die Initialisierung der Datenbank geladen. Soll die Datenbank bei jedem Test neu initialisiert werden, ist die Testklasse wie folgt zu annotieren:

@DirtiesContext(classMode = DirtiesContext.ClassMode.BEFORE_EACH_TEST_METHOD)
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.ANY)

subato2-data​

Neben der Datenbank müssen für einige Tests Aufgaben und Lösungen im Dateisystem vorhanden sein. Diese Fixtures werden unter src/test/resources/testfiles/subato2-data organisiert und müssen mit den Metadaten in der data.sql übereinstimmen. Das subato2-data Verzeichnis muss ggf. vor einem Testfall zurückgesetzt werden. Der folgende Code legt das Verzeichnis neu an:

@BeforeAll
public static void beforeAll(@Autowired PrepareSubatoDataDir dataDirCleanup, @Autowired SubatoTmpDirCleanup tmpDirCleanup) {
    dataDirCleanup.exec();
    tmpDirCleanup.exec();
}

Authentifizierung mocken​

Mit der Annotation @WithUserDetails("U_STAFF_C1A") werden (wenn MockMvc verwendet wird) die HTTP Requests in Integration Tests so simuliert, dass diese vom Benutzer mit dem angegebenen Benutzernamen (hier: U_STAFF_C1A) kommen.

Die Benutzer sind in data.sql anzulegen, das Benennungsschema ergibt sich aus:

  • U: Steht für Benutzer
  • STAFF: Steht für die Rolle staff
  • C1A: Steht dafür, dass der Benutzer im Kurs 1 die Admin-Berechtigung hat.

Die Benutzer sollten nach Möglichkeit wiederverwendet werden, damit die Testsuite wartbar bleibt.

Tests zu Autorisierung​

Jeder Endpunkt der REST-API sollte in Hinsicht auf die Authentifizierung/Autorisierung getestet werden, die von Policies sichergestellt wird.

Integration Tests für Controller​

Aktuell sind Integration Tests für Policies zu zeitaufwändig, weshalb die Authentifizierung/Autorisierung getestet werden soll, indem die Endpunkte der REST-API direkt verwendet werden. Die Integration Tests nutzen MockMvc, ein Minimalbeispiel findet sich in UpdateCourseTest.

Diese Tests sind so zu organisieren, dass sie sich im Package des Controllers befinden, der getestet werden soll. Für jeden Endpunkt ist eine Testklasse zu erstellen. Dieser Endpunkt soll dann darin umfassend getestet werden, d.h. verschiedene Eingaben und Benutzerkontexte sollen ausprobiert werden um sicherzustellen, dass keine groben Fehler vorhanden sind und dass die Endpunkte ausreichend geschützt sind. Der Aufwand ist dem Nutzen entsprechend aufzuwiegen.

Integration Tests für Policies​

Aufgrund des hohen Zeitaufwands sollen Policies nicht isoliert getestet werden. Stattdessen kann für jede Aktion ein Integration Test erstellt werden, der aus mehreren Testfällen besteht. Dabei wird nicht eine Policy isoliert getestet sondern das Zusammenspiel aller Policies um sicherzustellen, dass eine Aktion ausreichend geschützt ist.

Diese Tests sind im Package policy in der Testsuite zu organisieren.