Exceptions testen
Bei doubleSlash geben wir gerne unser Wissen weiter und lernen voneinander. Kürzlich durfte ich eine interne Schulung zum Thema Exception Handling halten. Neben Grundlagen haben wir auch eine Menge Bad und Best Practices kennengelernt und diese praktisch geübt. Dabei kam die Frage auf, wie man Exceptions eigentlich testet. Da die Übungen dieses Thema bisher nur beiläufig streiften, habe ich fürs nächste Mal ein Beispiel ergänzt, welches einige Möglichkeiten zeigt. Dieses teile ich hiermit gerne auch öffentlich.
Das Beispiel enthält zwei Methoden, welche Business-Logik simulieren, welche eine Exception wirft:
- Dabei simuliert die erste einen Stacktrace, bei dem die ursprüngliche Exception gewrappt und weitergegeben wird.
- Die zweite Methode wirft eine Exception ohne Cause, um keine Internas über Systemgrenzen hinweg preiszugeben. Dafür enthält die Nachricht hier eine Fehlerreferenz, mit deren Hilfe man sich an den Support wenden kann.
Die Tests unten zeigen Folgendes:
- verschiedene Wege, wie man prüfen kann, ob die Exceptions mit dem erwarteten Typ und Text geworfen werden
- wie man testet, ob der erwartete Root Cause enthalten ist
- wie man die Exception-Meldung auf erwartete Teilstrings testet
- wie man prüft, dass irgendwo im Stacktrace eine bestimmte Nachricht enthalten ist
- wie man die Exception-Nachricht anhand eines Patterns prüft und dabei Groß- und Kleinschreibung unberücksichtigt lässt
Hinweis: Damit das Beispiel funktioniert, benötigt man neben JUnit 5 auch AssertJ und Apache Commons Lang3 sowie SLF4J zum Loggen.
Bildnachweis: Das Titelbild zur Blogserie „Exception Handling“ basiert auf einer Grafik von mohamed_hassan auf Pixabay.
