Automatische Tests
Das Web-Portal beinhaltet eine umfangreiche Test-Suite unter src/test.
Es gibt hierbei keine Trennung zwischen Unit und Integrationstests.
Weitestgehend handelt es sich hierbei aber um Integrationstests.
Diese verwenden eine eigene Testdatenbank die auf dem lokalen Postgres-Server
mit dem Namen ps_test bereit stehen muss.
Leider wurde anfangs wenig darauf geachtet, dass die Tests unabhängig voneinander laufen. Es gibt daher an einigen Stellen Abhängigkeiten zwischen den Tests in der Form, dass (üblicherweise) später ausgeführte Tests bei ihren Assertions auf die Ergebnisse früher ausgeführter Tests aufbauen. Dies sollte in Zukunft unbedingt vermieden werden. Hilfreich kann es sein, die Tests mit der Transactional-Annotation zu versehen. Dadurch wird der Test jeweils mit einer Datenbank-Transaktion umgeben, welche mit einem Rollback endet. So bleibt der Datenbank-Zustand für jeden Test gleich. (Hat aber auch seine eigenen Fallstricke - siehe dazu should-my-tests-be-transactional)
Tipps
- Auf Unabhängigkeit zwischen den Test achten.
- Bei Problemen mit der lokalen Ausführung von Tests (Abhängigkeiten)
kann die
gates.testsuites.OrderedTestSuitehilfreich sein. - Bei Problemen mit lokalen Tests, die Dateien schreiben (z.B. Batch-Tests),
kann es helfen, den
target/test-Ordner zu löschen. (Clean)
Best Practices
Gliederung in Phasen
Für die Verständlichkeit von Tests ist es oft hilfreich, sie in die
üblicherweise auftretenden 3 Phasen zu gliedern. So sieht man auf
den ersten Blick, was eigentlich getestet wird. Idealerweise ist
auch der arrange-Teil leicht verständlich und baut nicht erst
über 30 Zeilen einen komplizierten globalen Zustand zusammen.
@Test
public void greeter_should_return_greeting(){
//arrange
Greeter g = new Greeter();
g.setGreeting("hello world");
//act
String greeting = g.greet();
//assert
assertEquals("hello world", greeting);
}
Tests mit Email-Versand
Für Use-Cases mit Email-Versand wurde ein alternativer Mailversand über einen lokalen Test-SMTP Server (z.B. FakeSMTP) eingerichtet. Dieser wird über die Spring-Konfigurationen MailConfiguration und MockMailConfiguration konfiguriert.
Die Aktivierung der MockMailConfiguration (derzeit bei den Spring-Profiles "dev" und "test") sorgt dabei dafür dass alle Mails an einen lokalen SMTP-Server auf localhost und Port 1025 gesendet werden.
Zusätzlich muss der Mailversand selbst aktiviert werden. Hierzu gibt es die Konfigurationseinstellung plusservices.mailservice.mode. Diese kann die Werte "mail", "dummy" oder "mock_mailserver" annehmen.
Bei "dummy" wird der Mailversand komplett deaktiviert, mit "mail" ist er eingeschaltet, bei "mock_mailserver" ebenfalls es wird aber vor dem Versand sicherheitshalber noch gecheckt, ob es sich wirklich um einen lokalen Test-SMTP-Server handelt.
Lokal Entwickeln mit Mock-Mailserver
- Spring-Profile "dev"
- plusservices.mailservice.mode = mock_mailserver
- FakeSMTP-Server lokal auf Port 1025 starten
Integrationstests mit Mock-Mailserver: siehe gates.mailing.service.MailIntegrationTest. Hierbei wird vom Test selbst ein Mock-Mailserver gestartet (FakeSMTP darf in diesem Fall nicht laufen), welcher anschließend genutzt wird, um die verschickten Mails zu prüfen.