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.OrderedTestSuite hilfreich 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.